From isms-bounces@lists.ietf.org Fri Jun 09 03:04:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fob2g-0000Md-2p; Fri, 09 Jun 2006 03:04:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fob2H-0008BP-PU for isms@ietf.org; Fri, 09 Jun 2006 03:04:01 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foavm-0002FR-8u for isms@ietf.org; Fri, 09 Jun 2006 02:57:20 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 42AB055F3E for ; Fri, 9 Jun 2006 08:57:17 +0200 (CEST) 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 13642-06; Fri, 9 Jun 2006 08:57:14 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id F15B955EF8; Fri, 9 Jun 2006 08:57:10 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id CD40A7475A2; Fri, 9 Jun 2006 08:57:08 +0200 (CEST) Date: Fri, 9 Jun 2006 08:57:08 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20060609065708.GA622@boskop.local> Mail-Followup-To: isms@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Cc: Subject: [Isms] updated issues and consensus proposals 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I like to closure on the TMSM issues. Attached is the list of issues plus excerpts of the email discussion plus concensus positions. Please check. Dave, it would be good if you can update the TMSM document before the cutoff so that we can move to last call mode on this document. Please also take into account the feedback provided by Sumanth Channabasappa on 25 May 2006. It would of course also be helpful to get the SSHSM update done before the cutoff. To the WG: I have not seen much feedback/discussion on the SSHSM document snapshot which Dave posted on 18 May 2006. It would be really helpful to get some feedback. If you do not want to read the whole document, please look for the [todo] and [discuss] markers and provide input to help us complete our documents. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=isms-tmsm-issues tmsm issue #1: meaning of authoritative in the context of TMSM (p28) We need to discuss what the meaning of authoritative would be in a TMSM environment. -> strawman: the meaning of authoritative in the sense of clock synchronization does not apply to TMSM instances and is irrelevant JH: From my limited understanding of what's going on here, this concept of "authoritative" is specific to the way USM works, and should be irrelevant to TMSM, at least at the abstract layer. DH: I think authoritative is not relevant to SSHSM, but there may be other TMSM models for whom authoritative may be meaningful. This is highly model-dependent, and may not mean the same type of authoritative as USM's authoritative. So until RFC3412 and RFC3411 are rewritten to remove securityEngineID from the ASIs, I think it would be wise to leave it, but we can point out that it is model-specific and may not be used by all models, and the local snmpEngineID will stauisyf the ASIs when it is not needed by a security model. -> consensus: TMSM explains that the meaning of authoritative is model-specific and must be clarified by the models. tmsm issue #2: purpose of msgSecurityParameters in TMSM (p28) We need to discuss whether the specific services provided in USM security from msgSecurityParameters still are needed, and how the Message Processing model provides this information to the security model via generateRequestMsg() and processIncomingMsg() primitives. RFC3412 specifies that "The data in the msgSecurityParameters field is used exclusively by the Security Model, and the contents and format of the data is defined by the Security Model. This OCTET STRING is not interpreted by the v3MP, but is passed to the local implementation of the Security Model indicated by the msgSecurityModel field in the message." -> strawman: we leave the contents of the msgSecurityParameters to the definition of a concrete TMSM instance JH: Agree DH: Agreed. -> consensus: see strawman tmsm issue #3: handling of msgFlags and securityLevel (p29) The text says that messages must be discarded if the underlying transport can't provide the requested security. How is yet to be determined, and may be model-specific or implementation-specific. -> strawman: yes, the implementation is implementation specific and the [discuss] should simply be dropped JH: There may be cases where the model needs to define exactly what it means for the underlying transport to provide the needed security; for example, SSHSM could decide that the level of security provided by an SSH connection depends on whether the null cipher is used, or not. Or, it could leave that up to the implementation or to configuration. In any event, actually determining what cipher is in use would certainly be implementation specific. -> consensus: Removed the discuss and state that it is model-specific and implementation-specific how this is determined. tmsm issue #4: notification state of NO initiated sessions (p31) We need to determine what state needs to be saved here. -> unclear what is needed here or what this issue is all about DH: The text preceding this discuss is incorrect, in that an outgoing notification does not cause the generation of a securityCache. This section basically says that a norification must cause the creation of a session if one does not exist. I do not think this requires any special processing other than getting the information from the target-mib (or whatever), which is likely to be model-specific. When I do the EOP for SSHSM, I will have a better idea of whteher there are any special issues for creating sessions for notifications. -> consensus: fix the text and remove the discuss tmsm issue #5: session table (p39) Should it be possible for a manager to create or modify rows in the session table? If so, then we may need the rowstatus object. If the session table is read-only then we can probably eliminate the rowstatus. If the tabel is not read-only, then we need to list the tables and objects and state why they are sensitive. -> strawman: the session table is read-only JH: The session table appears to be a means for exposing information about cached transport sessions. Since the actual sessions represented by these rows typically include things like actual transport connections and security state associated with those connections, it seems nonsensical for this table to be anything other than read-only. In fact, I'm not entirely convinced this essentially internal state should be exposed at all. DH: So an engine creates session entries for one of two circumstances 1) an outgoing message causes creation of a session. 2) an outgoing message from another engine causes creation of a session with this engine. Are those the only two things we need to care about? Either way, a sessionEntry should be created to record the session's existence. Although this makes me realize that we have not provided any text that discusses the opening of a session by a remote engine, and how the sessionTable gets populated. If those are the only two ways to create a session, then read-only should be fine. But these do not cover any callhome mechanism. RP: The only reasons I can think for having a session table visible to management are: - to monitor who is accessing a system at the moment - to provide a way for an administrator to terminate other sessions - for debugging None of these seems very persuasive to me. I suggest eliminating the table. DH: There is another use case you didn't mention. An authenticated CG could cause the creation of a session from the remote system to the local system for callback purposes. Such a callback approach has not been well-specified, and I am not sure such an approach is even viable, but it would require either read-write access to the session table, or another object that would cause a session to be created. Either way, the manager would probably want to see if a suitable session already existed before creating a new session. Callback has been debated, and the WG has waffled between "this really is needed for notifications when no session yet exists" to "we don't care about this because there is no customer demand for this feature." If all engines support mixing R/R and notification messages in the same session, then a manager could open a two-way session to each agent in case there are any notifications to be sent to it. I think this compares to the subscription model being discussed in netconf. There are issues with mixing that we have not yet discussed and which have been discussed in netconf, such as whether a long response (say to a getbulk) would block the delivery of notifications. There are issues with subscriptions that we have not discussed, such as the scalability of requiring managers to configure sessions to agents, especially when a network is recovering from, say, a power outage - with a subscription model, should the linkUp notifications be buffered by the agent until a manager sets up a session? In the meantime, I find the session table useful to try to understand what session info needs to be kept in an LCD for use by the elements of procedure, whether the LCD is in MIB format or a proprietary format. Using an implementation-neutral session MIB makes this clearer for me for now. We will need to keep session info available, and specify how one does a lookup based on the info available in the ASIs, in order to support the reuse of sessions (mixed or not). SNMP applications and the dispatcher and the message processing models do not know about sessions, and SSH does not know about securityN/M/L, so SSHSM needs to translate from the ASI parameters (transport + securityN/M/L) to SSH username/subsystem/transport somehow. A session table seems an appropriate place. SC: Callback has been debated, and the WG has waffled between "this really is needed for notifications when no session yet exists" to "we don't care about this because there is no customer demand for this feature." [s] I presume you mean call-home. IMHO it is important to support it (based on feedback from Service Providers) -> consensus: drop the session table since it will be read-only and mostly be a debugging tool; dropping the table reduces implementation costs. tmsm issue #6: security considerations (p40) How do we modify this section for an SNMP/SSH or other transport mapping security model? If the security model provides for securityName/Level/Model then some of the normal boilerplate is not true. -> strawman: TMSM instance specific text goes into the document which defines the TMSM instance - drop the discuss. JH: Agree. Each TMSM is going to have to have security considerations which depend on the underlying transport and on how it is being used. -> consensus: goes away once we have removed the session table tmsm issue #7: transport type (p40) How do we add a new TransportType? I am not sure, but the underlying question might be whether we use generic TransportAddress and TransportAddressType TCs or stick with the traditional TDomain and TAddress TCs. -> strawman: We use TDomain/TAddress and every TMSM instance provides appropriate TCs and OID constants for the specific SNMP transport. JH: I'm not sure I understand what you're proposing; maybe I need to go back and look at SNMPv3 again. My recollection from the interim was that we came to the conclusion that a new transport address type would be necessary to describe SSH endpoints by name. -> constants: see strawman tmsm issue #8: mpsp vs smsp The ID right now uses the term "message processing security processor" (MPSP) to refer to the piece which does security processing in the security subsystem. This somehow sounds like a misnomer. Should this not be the "security model security processor" (SMSP)? This way, we would device a "transport mapping security model" into the two pieces TMSP - transport mapping security processor SMSP - security model security processor since the message processing model should actually not be involed in all this. -> strawman: change terms as suggested --sdtB3X0nJg68CQEu Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --sdtB3X0nJg68CQEu-- From isms-bounces@lists.ietf.org Fri Jun 09 09:51:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FohOQ-0007YD-AE; Fri, 09 Jun 2006 09:51:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FohOO-0007Y8-Dn for isms@ietf.org; Fri, 09 Jun 2006 09:51:16 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FohON-0001IO-48 for isms@ietf.org; Fri, 09 Jun 2006 09:51:16 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc11) with SMTP id <20060609135113m1100hd10ke>; Fri, 9 Jun 2006 13:51:14 +0000 From: "David Harrington" To: , Subject: RE: [Isms] updated issues and consensus proposals Date: Fri, 9 Jun 2006 09:50:11 -0400 Message-ID: <061b01c68bcb$a0d91100$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20060609065708.GA622@boskop.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaLkvIbOgGGo7HrQEifIipUSgzg8AANcrSQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, I plan to publish a new SSHSM revision today. I think it is much easier to follow the EOP than the last revision, and some duplication of text has been reduced. So you might want to wait for that one. On the other hand, If you look at the revision I published in May, it may be easier to see the changes made between that and the previous revision. The new revision will be harder to review using diffs. I have reordered a number of the paragraphs in the new revision, and most of the [todo] and [discuss] markers have been removed in the new revision. Since I was getting no feedback, I simply discussed the [discuss]es with myself and went with the consensus ;-) The SSHSM MIB module has nothing in it right now, except the transportAddress TC. It probably should have error counters. When reviewing the greatly-improved EOP, the WG should pay attention to what error counters they think should be in the MIB. We're getting closer to the end on these documents. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Friday, June 09, 2006 2:57 AM > To: isms@ietf.org > Subject: [Isms] updated issues and consensus proposals > > Hi, > > I like to closure on the TMSM issues. Attached is the list of issues > plus excerpts of the email discussion plus concensus positions. Please > check. > > Dave, it would be good if you can update the TMSM document before the > cutoff so that we can move to last call mode on this document. Please > also take into account the feedback provided by Sumanth Channabasappa > on 25 May 2006. > > It would of course also be helpful to get the SSHSM update done before > the cutoff. > > To the WG: I have not seen much feedback/discussion on the SSHSM > document snapshot which Dave posted on 18 May 2006. It would be really > helpful to get some feedback. If you do not want to read the whole > document, please look for the [todo] and [discuss] markers and provide > input to help us complete our documents. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jun 12 03:23:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpglv-0005BA-H2; Mon, 12 Jun 2006 03:23:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpglv-0005B5-8y for isms@ietf.org; Mon, 12 Jun 2006 03:23:39 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpglt-00066U-VE for isms@ietf.org; Mon, 12 Jun 2006 03:23:39 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 0695E5608F for ; Mon, 12 Jun 2006 09:23:37 +0200 (CEST) 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 01347-01; Mon, 12 Jun 2006 09:23:35 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id E45A655F83; Mon, 12 Jun 2006 09:23:34 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id F1619747D70; Mon, 12 Jun 2006 09:23:32 +0200 (CEST) Date: Mon, 12 Jun 2006 09:23:32 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20060612072332.GA1761@noname> Mail-Followup-To: isms@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Isms] montreal wg meeting 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, the first draft schedule for the Montreal IETF is now online: https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=66 The ISMS meeting so far is scheduled for Wednesday 15:10-16:10. Note that the agenda is still subject to changes. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jun 13 20:06:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqIuK-0002Zv-Hs; Tue, 13 Jun 2006 20:06:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqIu5-0002RX-Hd; Tue, 13 Jun 2006 20:06:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHxn-0005cW-7D; Tue, 13 Jun 2006 19:06:23 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqHiv-0005Zw-Rz; Tue, 13 Jun 2006 18:51:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5DMo1mU014127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Jun 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FqHhx-0006cY-Cy; Tue, 13 Jun 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 13 Jun 2006 18:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-secshell-03.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Secure Shell Security Model for SNMP Author(s) : J. Salowey, D. Harrington Filename : draft-ietf-isms-secshell-03.txt Pages : 47 Date : 2006-6-13 This memo describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-secshell-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-secshell-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-13151052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-secshell-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-secshell-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-13151052.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Mon Jun 19 20:40:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsUI1-0005G3-Df; Mon, 19 Jun 2006 20:40:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsUHz-0005FD-Si for isms@ietf.org; Mon, 19 Jun 2006 20:40:19 -0400 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsUHy-00019p-Oo for isms@ietf.org; Mon, 19 Jun 2006 20:40:19 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc13) with SMTP id <20060620004015m1300fvo2ge>; Tue, 20 Jun 2006 00:40:15 +0000 From: "David Harrington" To: "'Sumanth Channabasappa'" , Subject: RE: [Isms] Comments: draft-ietf-isms-tmsm-02 Date: Mon, 19 Jun 2006 20:39:04 -0400 Message-ID: <11b701c69401$eec0aac0$0400a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaUAaYvrnJFh5+TQMu/jpIR1CtGOA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d6d8241647d2894221526b1bc205882 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1495160576==" Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1495160576== Content-Type: multipart/alternative; boundary="----=_NextPart_000_11B8_01C693E0.67AF0AC0" This is a multi-part message in MIME format. ------=_NextPart_000_11B8_01C693E0.67AF0AC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi comments inline. (sorry for the html format; trying to respond in text-only would have made things harder. _____ From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com] Sent: Thursday, May 25, 2006 5:52 PM To: isms@ietf.org Subject: [Isms] Comments: draft-ietf-isms-tmsm-02 Folks, As a follow-up to volunteering for the review of draft-ietf-isms-tmsm-xx, here are a set of preliminary comments, some questions and requested clarifications. They are mostly a collective effort (most of them are from Josh Littlefield and some from myself, as indicated in []). regards Sumanth - [C#1] 2.2.1 [Sumanth] Are TMSM TMSP and TMSM MPSP really independent as defined in the figure? Also see: comments on 2.2.2.2 (C#5) and 4.2 (C#8) No. But ascii art makes it hard to fit all connections within the line length limits of an I-D. They are connected, through the cache references, passed through the ASIs. - [C#2] 2.3.1 [Sumanth] This leaves a lot to the security model definitions. Can we make it a requirement for the security models to define constraints listed here. I'm not sure I understand your concerns here. The TMSM only defines an architecture, and the security models need to provide the details of the specification. But there are certain behaviors we need to know are standardized regardless of the security model being used. So do you want the TMSM to do less and give the security models more freedom to define their behaviors, or do you want the TMSM to impose additinal requirements on the security models, giving the security models less freedom? - [C#3] 2.3.3, 1st para (pg 19): "The cryptographic protocols used to establish keys for a TMSM-based security model session SHOULD ensure that fresh new session keys are generated for each session." [Josh] Would this rule out TLS session resumption, which uses an abbreviated handshake to resume a cached session? Shouldn't this be a transport protocol security issue, not a TMSM issue? [Sumanth] My assumption is that 'session resumption' should be allowed (e.g. TLS). Can we include this explicitly and have some considerations (when to use and when not to). Since this is a SHOULD and not a MUST, I think there is room for a TLS resume to be included in a TLS model. Given that there is a SHOULD here, the TLS model should justify when it is acceptable to not follow the TMSM SHOULD. I think that would the right place to discuss the TLS-specific option of session resumption (as well as in security consdierations of such a TLS model). - [C#4] 2.2.2.1, 4th para (pg 14): "Hence, the authentication of a transport layer identity plays an important role and must be considered by any TMSM, and user authentication must be available via the transport layer security protocol." [Josh] Should avoid talking about "user authentication." There are no "users" in the abstract model, only securityNames. Perhaps the requirement is for of some form of peer principal authentication. Yes. - [C#5] 2.2.2.2, final para (pg 15): "This may be highly undesirable, however, if it creates a dependency between a security model and an access control model, just as it is undesirable that the TMSM approach creates a dependency between a TMSP and an MPSP." [Josh, Sumanth] While I agree that interdependence between a security model and an access control model is undesirable, I don't equate that with the dependency between a TMSP and an MPSP. I think the latter is unavoidable in cases where the transport provides all security functions, even though SNMP expects them to come from the message processor. The SM-specific MPSP would seem to have to be tailored to the TMSP capabilities in all cases. In fact, they might be bound together, even though they provide two separate abstract interfaces. The RFC3411 architecture does not permit having security provided at a lower layer. The conceptual modularity is important to maintain, but we blew it, so now we need to accommodate having security performed at different places depending on the security model (TMSM vs USM). That's unfortunate, but unavoidable at this point. - [C#6] 2.3, 3rd para (pg 17): "It is important to note that the architecture described in [RFC3411] does not include a session selector in the Abstract Service Interfaces, and neither is that done for this architectural extension, so an SNMP application cannot select the session except by passing a unique combination of securityName, securityModel, and securityLevel." [Josh, Sumanth] Add "transport address" to the list of items used to select the session. This would then be consistent with the text in 2.3.1. done - [C#7] 4.2 (pg 25): [Josh] The TMSM is described as an entity with an (abstract) interface with a specific TMSM-based security model below it, but in general the TMSM isn't otherwise described as a component. It would seem more clear to talk about the TMSP here, or perhaps the TMSM TMSP, with the TMSP providing sendMessage() and recvMessage(), and a security-model-specific TMSP instance providing txMessage(), rxMessage(), openSession(), etc. [Josh] The value of the layering between sendMessage() and txMessage(), and between recvMessage() and rxMessage() (the layering between a generic TMSP and a SM-specific TMSP) is not obvious. It would seem, at the least, that the securityModel would need to be passed to sendMessage() in order to allow this generic layer to locate the specific TMSP. If this is retrieve by the generic TMSP from the tmStateReference (implied by section 7), then section 7 must be normative about some of the required content of tmStateReference. [Josh] Since the recvMessage() ASI is implemented by the Dispatcher and called by the TMSP, it doesn't seem to make sense that tmStateReference is an OUTPUT. It should be an INPUT, since I believe it is produced by the TMSP and provided to the Dispatcher, as is also true for the incomingMessage. The same would seem to be true for the tmStateReference argument in rxMessage(). Similarly, why would sessionID be an OUTPUT, indicating it is produced by the Dispatcher? There has been some discussion about whether to define a generic transport mapping subsystem (which RFC3411 should have done), and then treat SSHSM-TPSM as simply a transport mapping to SSH, and so on. - [C#8] 4.2 (pg 26): If the use of sessions is hidden by the TMSP, then it isn't clear why the ASI to the SM-specific TMSP provides openSession() and closeSession() mechanisms. Further, the sessionID is not INPUT to any ASI other than closeSession(), so what is the point of allowing one to open a specific session? Similarly, what is the point of producing sessionID from the sendMessage() call? The Dispatcher has no obvious use for a sessionID (and no ASI to close a session). Eliminated sessionID. The combination of transport and securityNML provide the needed index into the LCD. - [C#9] 6.2, para 4 (pg 28): "[discuss] We need to discuss what the meaning of authoritative would be in a TMSM environment, whether the specific services provided in USM security from msgSecurityParameters still are needed, and how the Message Processing model provides this information to the security model via generateRequestMsg() and processIncomingMsg() primitives." [Josh] While "authoritative", as relates to the setting of securityEngineID is defined clearly in RFC 3412, I don't think TMSM can make any blanket statements about whether securityEngineID (the authoritative SNMP entity) is needed by the underlying security model. There may be TMSM-based security models that model themselves on USM for authentication of the connection originator (client), while using transport mechanisms for authentication of the server, and require securityEngineID to be used in a way similar to USM. If it isn't used, then it would be up to each specific TMSM model to state that. Likewise, I think it's up to the specific TMSM model to define the use of msgSecurityParameters. [Josh] Regarding "authoritative", this has been discussed on the mailing list and this is in agreement with the current consensus (?) -- refer issue #1 on the mailing list Regarding "msgSecurityParameters', this has been discussed on the mailing list and this is in agreement with the current consensus (?) -- refer issue #2 on the mailing list Done. -- [C#10] 8 & 9 (pg 29+): [Josh] How does the tmStateReference get into and out of the MPSP? Are the Dispatcher to MP ASIs augmented to pass this reference? Yes. -- [C#11] 9 (pg 30): [Josh] Now this text makes me think that the openSession() and closeSession() ASIs were between the MPSP and the TMSP. Or, does the MPSP accomplish the actions described here against the TMSP by internal interfaces? Fixed so that openSession() and closeSession() occur only via the TMSP. -- [C#12] 11 (Page 33, 34) [sumanth] "tmsmSessionSpinLock" - usage is not very clear "tmsmSessionMaxSupported" - given the interpretation of zero is 'dynamic', what about the case when the max is zero (resource constraints). Recommend changing to it a MAX value for dynamic or something else "tmsmSessionEngineID" -- implies that there is one Engine ID per session. Do we need to make this clear elsewhere? We need to decide what needs to be in the MIB module yet. That will depend on whether we reach consensus on the elements of procedure. ------=_NextPart_000_11B8_01C693E0.67AF0AC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
comments inline.
(sorry for the html format; trying to respond = in text-only=20 would have made things harder.

From: Sumanth Channabasappa=20 [mailto:sumanth@cablelabs.com]
Sent: Thursday, May 25, 2006 = 5:52=20 PM
To: isms@ietf.org
Subject: [Isms] Comments:=20 draft-ietf-isms-tmsm-02

Folks,
 
As a=20 follow-up to volunteering for the review of draft-ietf-isms-tmsm-xx, = here are=20 a set of preliminary comments, some questions and requested = clarifications.=20
 
They are=20 mostly a collective effort (most of them are from Josh Littlefield and = some=20 from myself, as indicated in []).
 
regards
Sumanth
 
 

- [C#1] 2.2.1=20

[Sumanth] Are = TMSM TMSP=20 and TMSM MPSP really independent as defined in the=20 figure?

 

Also see: = comments on=20 2.2.2.2 (C#5) and 4.2 (C#8) 

 

No. But = ascii=20 art makes it hard to fit all connections within the line length = limits of=20 an I-D.

They are = connected,=20 through the cache references, passed through the=20 ASIs. 

 

 

- [C#2] 2.3.1=20

[Sumanth] This leaves a lot to the = security=20 model definitions. Can we make it a requirement for the security = models to=20 define constraints listed here. 

 

I'm not = sure I=20 understand your concerns here. The TMSM only defines an architecture, = and the=20 security models need to provide the details of the specification. But = there=20 are certain behaviors we need to know are standardized regardless of = the=20 security model being used. So do you want the TMSM to do less and give = the=20 security models more freedom to define their behaviors, or do you = want=20 the TMSM to impose additinal requirements on the security models, = giving the=20 security models less freedom?

 

 

- [C#3] 2.3.3, = 1st para=20 (pg 19):

 

"The = cryptographic=20 protocols used to establish keys for a TMSM-based security model = session=20 SHOULD ensure that fresh new session keys are generated for each=20 session."

 

[Josh] Would = this rule out=20 TLS session resumption, which uses an abbreviated handshake to resume = a cached=20 session?  Shouldn't this = be a=20 transport protocol security issue, not a TMSM = issue?

 

[Sumanth] My = assumption is=20 that 'session resumption' should be allowed (e.g. TLS). Can we include = this=20 explicitly and have some considerations (when to use and when not=20 to).

 

Since = this is a SHOULD=20 and not a MUST, I think there is room for a TLS resume to be included = in a TLS=20 model. Given that there is a SHOULD here, the TLS model should justify = when it=20 is acceptable to not follow the TMSM SHOULD. I think that would the = right=20 place to discuss the TLS-specific option of session resumption (as = well as in=20 security consdierations of such a TLS = model).

 

 

- [C#4] 2.2.2.1, = 4th para=20 (pg 14):

 

"Hence, the = authentication=20 of a transport layer identity plays an important role and must be = considered=20 by any TMSM, and user authentication must be available via the = transport layer=20 security protocol."

 

[Josh] Should = avoid=20 talking about "user authentication." =20 There are no "users" in the abstract model, only = securityNames.  Perhaps the requirement is = for of some=20 form of peer principal authentication. 

 

Yes. 

 

 

- [C#5] 2.2.2.2, = final=20 para (pg 15):

"This may be = highly=20 undesirable, however, if it creates a dependency between a security = model and=20 an access control model, just as it is undesirable that the TMSM = approach=20 creates a dependency between a TMSP and an = MPSP."

 

[Josh, Sumanth] = While I=20 agree that interdependence between a security model and an access = control=20 model is undesirable, I don't equate that with the dependency between = a TMSP=20 and an MPSP.  I think = the latter=20 is unavoidable in cases where the transport provides all security = functions,=20 even though SNMP expects them to come from the message processor.  The SM-specific MPSP would = seem to=20 have to be tailored to the TMSP capabilities in all cases.  In fact, they might be bound = together,=20 even though they provide two separate abstract interfaces. 

 

The = RFC3411=20 architecture does not permit having security provided at a lower = layer. The=20 conceptual modularity is important to maintain, but we blew it, so now = we need=20 to accommodate having security performed at different places depending = on the=20 security model (TMSM vs USM). That's unfortunate, but unavoidable at = this=20 point.

 

- [C#6] 2.3, 3rd = para (pg=20 17):

 

"It is important = to note=20 that the architecture described in [RFC3411] does not include a = session=20 selector in the Abstract Service Interfaces, and neither is that done = for this=20 architectural extension, so an SNMP application cannot select the = session=20 except by passing a unique combination of securityName, securityModel, = and=20 securityLevel."

 

[Josh, Sumanth] = Add=20 "transport address" to the list of items used to select the = session.  This would then be = consistent with the=20 text in 2.3.1. 

 

done 

 

- [C#7] 4.2 (pg=20 25):

 

[Josh] The TMSM = is=20 described as an entity with an (abstract) interface with a specific = TMSM-based=20 security model below it, but in general the TMSM isn't otherwise = described as=20 a component.  It would = seem more=20 clear to talk about the TMSP here, or perhaps the TMSM TMSP, with the = TMSP=20 providing sendMessage() and recvMessage(), and a = security-model-specific TMSP=20 instance providing txMessage(), rxMessage(), openSession(),=20 etc.

 

 

[Josh] The value = of the=20 layering between sendMessage() and txMessage(), and between = recvMessage() and=20 rxMessage() (the layering between a generic TMSP and a SM-specific = TMSP) is=20 not obvious.   

 

 It would seem, at the = least, that=20 the securityModel would need to be passed to sendMessage() in order to = allow=20 this generic layer to locate the specific TMSP.  If this is retrieve by the = generic=20 TMSP from the tmStateReference (implied by section 7), then section 7 = must be=20 normative about some of the required content of=20 tmStateReference.

 

[Josh] Since the = recvMessage() ASI is implemented by the Dispatcher and called by the = TMSP, it=20 doesn't seem to make sense that tmStateReference is an OUTPUT.  It should be an INPUT, since = I believe=20 it is produced by the TMSP and provided to the Dispatcher, as is also = true for=20 the incomingMessage.  = The same=20 would seem to be true for the tmStateReference argument in = rxMessage().  Similarly, why would = sessionID be an=20 OUTPUT, indicating it is produced by the Dispatcher? 

 

There = has been=20 some discussion about whether to define a generic transport = mapping=20 subsystem (which RFC3411 should have done), and then treat SSHSM-TPSM = as=20 simply a transport mapping to SSH, and so on.

 

- [C#8] 4.2 (pg=20 26):

If the use of = sessions is=20 hidden by the TMSP, then it isn't clear why the ASI to the SM-specific = TMSP=20 provides openSession() and closeSession() mechanisms.  Further, the sessionID is = not INPUT to=20 any ASI other than closeSession(), so what is the point of allowing = one to=20 open a specific session? =20 Similarly, what is the point of producing sessionID from the=20 sendMessage() call?  The = Dispatcher has no obvious use for a sessionID (and no ASI to close a=20 session). 

 

Eliminated sessionID.=20 The combination of transport and securityNML provide the needed index = into the=20 LCD. 

 

- [C#9] 6.2, = para 4 (pg=20 28):

 

"[discuss] We = need to=20 discuss what the meaning of authoritative would be in a TMSM = environment,=20 whether the specific services provided in USM security from=20 msgSecurityParameters still are needed, and how the Message Processing = model=20 provides this information to the security model via = generateRequestMsg() and=20 processIncomingMsg() primitives."

 

[Josh] While=20 "authoritative", as relates to the setting of securityEngineID is = defined=20 clearly in RFC 3412, I don't think TMSM can make any blanket = statements about=20 whether securityEngineID (the authoritative SNMP entity) is needed by = the=20 underlying security model.  = There=20 may be TMSM-based security models that model themselves on USM for=20 authentication of the connection originator (client), while using = transport=20 mechanisms for authentication of the server, and require = securityEngineID to=20 be used in a way similar to USM. =20 If it isn't used, then it would be up to each specific TMSM = model to=20 state that.

Likewise, I = think it's up=20 to the specific TMSM model to define the use of=20 msgSecurityParameters.

 

[Josh]=20

Regarding = "authoritative",=20 this has been discussed on the mailing list and this is in agreement = with the=20 current consensus (?) -- refer issue #1 on the mailing=20 list

 

Regarding=20 "msgSecurityParameters', this has been discussed on the mailing list = and this=20 is in agreement with the current consensus (?) -- refer issue #2 on = the=20 mailing list 

 

Done. 

 

 

-- [C#10] 8 = & 9 (pg=20 29+):

 

[Josh] How does = the=20 tmStateReference get into and out of the MPSP?  Are the Dispatcher to MP = ASIs=20 augmented to pass this reference? 

 

Yes. 

 

 

-- [C#11] 9 (pg=20 30):

 

[Josh] Now this = text makes=20 me think that the openSession() and closeSession() ASIs were between = the MPSP=20 and the TMSP.  Or, does = the MPSP=20 accomplish the actions described here against the TMSP by internal=20 interfaces? 

 

Fixed so = that=20 openSession() and closeSession() occur only via the=20 TMSP. 

 

-- [C#12] 11 = (Page 33,=20 34)

[sumanth]

 

"tmsmSessionSpinLock" -=20 usage is not very clear

 

"tmsmSessionMaxSupported"=20 - given the interpretation of zero is 'dynamic', what about the case = when the=20 max is zero (resource constraints). Recommend changing to it a MAX = value for=20 dynamic or something else

 

"tmsmSessionEngineID" --=20 implies that there is one Engine ID per session. Do we need to make = this clear=20 elsewhere? 

 

We need = to decide what=20 needs to be in the MIB module yet. That will depend on whether we = reach=20 consensus on the elements of procedure.

 

 

 

------=_NextPart_000_11B8_01C693E0.67AF0AC0-- --===============1495160576== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --===============1495160576==-- From isms-bounces@lists.ietf.org Mon Jun 19 20:45:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsUN3-0003BN-Mg; Mon, 19 Jun 2006 20:45:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsUN1-00038N-N2 for isms@ietf.org; Mon, 19 Jun 2006 20:45:31 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsUN0-0002VA-FX for isms@ietf.org; Mon, 19 Jun 2006 20:45:31 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc11) with SMTP id <20060620004529m1100b4ajje>; Tue, 20 Jun 2006 00:45:29 +0000 From: "David B Harrington" To: Date: Mon, 19 Jun 2006 20:44:17 -0400 Message-ID: <11bf01c69402$a99f6980$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaUAfOp4YQfGtUET+a13vD2dGbywQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Isms] Name change X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, Would anybody object to my changing tmStateReference to tmSessionReference or simply sessionReference in both documents? David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 21 16:08:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft90P-0003ue-Sq; Wed, 21 Jun 2006 16:08:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft90O-0003uL-TV for isms@ietf.org; Wed, 21 Jun 2006 16:08:52 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft90N-00079G-BL for isms@ietf.org; Wed, 21 Jun 2006 16:08:52 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 6E90555F80 for ; Wed, 21 Jun 2006 22:08:50 +0200 (CEST) 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 24028-09 for ; Wed, 21 Jun 2006 22:08:48 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 4275955FA5 for ; Wed, 21 Jun 2006 22:08:48 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id C8EEE75E29A; Wed, 21 Jun 2006 22:08:46 +0200 (CEST) Resent-From: j.schoenwaelder@iu-bremen.de Resent-Date: Wed, 21 Jun 2006 22:08:46 +0200 Resent-Message-ID: <20060621200846.GA3538@boskop.local> Resent-To: isms@ietf.org Received: from merkur.iu-bremen.de ([unix socket]) by merkur (Cyrus v2.2.12) with LMTPA; Wed, 21 Jun 2006 22:03:09 +0200 X-Sieve: CMU Sieve 2.2 Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by merkur.iu-bremen.de (Postfix) with ESMTP id E87A979EAA3C6 for ; Wed, 21 Jun 2006 22:03:08 +0200 (CEST) Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id DAADD55F56 for ; Wed, 21 Jun 2006 22:03:08 +0200 (CEST) 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 23440-10 for ; Wed, 21 Jun 2006 22:03:06 +0200 (CEST) Received: from megatron.ietf.org (optimus.ietf.org [156.154.16.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id C691A55F5E for ; Wed, 21 Jun 2006 22:03:02 +0200 (CEST) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8uW-0006TL-5D; Wed, 21 Jun 2006 16:02:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8iI-0000an-FP for i-d-announce@ietf.org; Wed, 21 Jun 2006 15:50:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft8iI-0002uD-DK for i-d-announce@ietf.org; Wed, 21 Jun 2006 15:50:10 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ft8iA-0001md-Nw for i-d-announce@ietf.org; Wed, 21 Jun 2006 15:50:10 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5LJo2Rx031603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 21 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ft8iA-0003mq-4o for i-d-announce@ietf.org; Wed, 21 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 21 Jun 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Status: No, score=-1.937 tagged_above=-30 required=6.31 tests=[BAYES_00=-2.312, MIME_BOUND_NEXTPART=0.375] X-Spam-Score: -1.937 X-Spam-Level: X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.3 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: Subject: [Isms] I-D ACTION:draft-narayan-isms-sshsm-radius-00.txt X-BeenThere: isms@lists.ietf.org Reply-To: internet-drafts@ietf.org List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Resent-Date: Wed, 21 Jun 2006 16:08:53 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RADIUS Usage for SNMP SSH Security Model Author(s) : K. Narayan, D. Nelson Filename : draft-narayan-isms-sshsm-radius-00.txt Pages : 12 Date : 2006-6-21 The Secure Shell Security Model (SSHSM) describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. This memo describes the usage of the Secure Shell Security Model with a RADIUS authentication and authorization system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-narayan-isms-sshsm-radius-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-narayan-isms-sshsm-radius-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-narayan-isms-sshsm-radius-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-21141205.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-narayan-isms-sshsm-radius-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-narayan-isms-sshsm-radius-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-21141205.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Thu Jun 22 16:20:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtVf0-0008En-75; Thu, 22 Jun 2006 16:20:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtVez-0008ET-AV for isms@ietf.org; Thu, 22 Jun 2006 16:20:17 -0400 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtVey-00081k-0b for isms@ietf.org; Thu, 22 Jun 2006 16:20:17 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc13) with SMTP id <20060622202014m1300g54pae>; Thu, 22 Jun 2006 20:20:15 +0000 From: "David B Harrington" To: Date: Thu, 22 Jun 2006 16:19:02 -0400 Message-ID: <17a501c69639$1acaabf0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <20060602204201.GA17337@boskop.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaGhYEFhj7VM4tgQ6mZ5/OzKP72HQPssQ/w X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: isms@ietf.org Subject: [Isms] RE: Underspecified CallHome X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi JS, Do you want to try to reach consensus on some text for the SSHSM document? dbh > -----Original Message----- > From: owner-netconf@ops.ietf.org > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Friday, June 02, 2006 4:42 PM > To: Phil Shafer > Cc: Andy Bierman; Balazs Lengyel; Netconf (E-mail) > Subject: Re: Underspecified CallHome > > On Fri, Jun 02, 2006 at 04:29:48PM -0400, Phil Shafer wrote: > > > BEEP handles the device-initiated connection easily, and one can > > use 'sshd -i' on the device side to pass a device-initiated > connection > > into the ssh daemon code, allowing us to preserve the existing > > client/server relationship in netconf. I'm clueless about how soap > > would handle this. > > While I love the simplicity of this approach (agent establishes the > TCP connection and once established it takes over the SSH server > role), I had the feeling that security folks seriously disliked it > during the ISMS discussions. Instead, they seemed to prefer something > where you have to use host-key authentication and you end up with > different notions of access control rules since you have different > authenticated identities to deal with. > > I like to see a common approach to deal with "agent" initiated > connections between netconf and ISMS and as I said I love the > simplicity of what you propose for netconf... > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jun 23 11:31:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtndE-0001wY-Ik; Fri, 23 Jun 2006 11:31:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtndC-0001wP-MW for isms@ietf.org; Fri, 23 Jun 2006 11:31:38 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtndC-0004hG-6W for isms@ietf.org; Fri, 23 Jun 2006 11:31:38 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.6/8.13.6) with ESMTP id k5NFVadW005839; Fri, 23 Jun 2006 09:31:36 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Isms] Comments: draft-ietf-isms-tmsm-02 Date: Fri, 23 Jun 2006 09:31:36 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] Comments: draft-ietf-isms-tmsm-02 Thread-Index: AcaUAaYvrnJFh5+TQMu/jpIR1CtGOAC1rYiw From: "Sumanth Channabasappa" To: "David Harrington" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0053883018==" Errors-To: isms-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0053883018== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C696DA.1D5E9942" This is a multi-part message in MIME format. ------_=_NextPart_001_01C696DA.1D5E9942 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David et al,=20 =20 Some responses and comments inline =20 - [C#1] 2.2.1=20 [Sumanth] Are TMSM TMSP and TMSM MPSP really independent as defined in the figure? =20 Also see: comments on 2.2.2.2 (C#5) and 4.2 (C#8)=20 =20 No. But ascii art makes it hard to fit all connections within the line length limits of an I-D. They are connected, through the cache references, passed through the ASIs.=20 =20 [s] Understood. I would suggest adding a note at the end of the diagram, if possible. =20 =20 - [C#2] 2.3.1=20 [Sumanth] This leaves a lot to the security model definitions. Can we make it a requirement for the security models to define constraints listed here.=20 =20 I'm not sure I understand your concerns here. The TMSM only defines an architecture, and the security models need to provide the details of the specification. But there are certain behaviors we need to know are standardized regardless of the security model being used. So do you want the TMSM to do less and give the security models more freedom to define their behaviors, or do you want the TMSM to impose additinal requirements on the security models, giving the security models less freedom? [s] I was leaning towards the latter, keeping in mind that there may be security requirements that need to be 'addressed' by all security models in a uniform manner. =20 =20 - [C#3] 2.3.3, 1st para (pg 19): =20 "The cryptographic protocols used to establish keys for a TMSM-based security model session SHOULD ensure that fresh new session keys are generated for each session." =20 [Josh] Would this rule out TLS session resumption, which uses an abbreviated handshake to resume a cached session? Shouldn't this be a transport protocol security issue, not a TMSM issue? =20 [Sumanth] My assumption is that 'session resumption' should be allowed (e.g. TLS). Can we include this explicitly and have some considerations (when to use and when not to). =20 Since this is a SHOULD and not a MUST, I think there is room for a TLS resume to be included in a TLS model. Given that there is a SHOULD here, the TLS model should justify when it is acceptable to not follow the TMSM SHOULD. I think that would the right place to discuss the TLS-specific option of session resumption (as well as in security consdierations of such a TLS model).=20 [s] Agree =20 =20 =20 =20 =20 =20 Thanks Sumanth ------_=_NextPart_001_01C696DA.1D5E9942 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
David et al,
 
Some responses and comments = inline
 

- [C#1] 2.2.1=20

[Sumanth] Are = TMSM TMSP=20 and TMSM MPSP really independent as defined in the=20 figure?

 

Also see: = comments on=20 2.2.2.2 (C#5) and 4.2 (C#8) 

 

No. But = ascii=20 art makes it hard to fit all connections within the line length = limits of=20 an I-D.

They are = connected,=20 through the cache references, passed through the=20 ASIs. 

 

[s] Understood. I would suggest adding a note at the = end of the=20 diagram, if possible.

 

 

- [C#2] 2.3.1=20

[Sumanth] This leaves a lot to the = security=20 model definitions. Can we make it a requirement for the security = models to=20 define constraints listed here. 

 

I'm not = sure I=20 understand your concerns here. The TMSM only defines an architecture, = and the=20 security models need to provide the details of the specification. But = there=20 are certain behaviors we need to know are standardized regardless of = the=20 security model being used. So do you want the TMSM to do less and give = the=20 security models more freedom to define their behaviors, or do you = want=20 the TMSM to impose additinal requirements on the security models, = giving the=20 security models less freedom?

[s] I was = leaning=20 towards the latter, keeping in mind that there may be security = requirements=20 that need to be 'addressed' by all security models in a uniform=20 manner.

 

 

- [C#3] 2.3.3, = 1st para=20 (pg 19):

 

"The = cryptographic=20 protocols used to establish keys for a TMSM-based security model = session=20 SHOULD ensure that fresh new session keys are generated for each=20 session."

 

[Josh] Would = this rule out=20 TLS session resumption, which uses an abbreviated handshake to resume = a cached=20 session?  Shouldn't this = be a=20 transport protocol security issue, not a TMSM = issue?

 

[Sumanth] My = assumption is=20 that 'session resumption' should be allowed (e.g. TLS). Can we include = this=20 explicitly and have some considerations (when to use and when not=20 to).

 

Since this is a=20 SHOULD and not a MUST, I think there is room for a TLS resume to be = included=20 in a TLS model. Given that there is a SHOULD here, the TLS model = should=20 justify when it is acceptable to not follow the TMSM SHOULD. I think = that=20 would the right place to discuss the TLS-specific option of session = resumption=20 (as well as in security consdierations of such a TLS model). 

[s]=20 Agree

 

 

   

 

     =    =20  

 

 Thanks

Sumanth

<= /BLOCKQUOTE> ------_=_NextPart_001_01C696DA.1D5E9942-- --===============0053883018== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --===============0053883018==-- From isms-bounces@lists.ietf.org Fri Jun 23 16:36:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtsNk-0004oE-Ka; Fri, 23 Jun 2006 16:36:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtsNj-0004mT-Do for isms@ietf.org; Fri, 23 Jun 2006 16:35:59 -0400 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtsNi-0002Fv-43 for isms@ietf.org; Fri, 23 Jun 2006 16:35:59 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc12) with SMTP id <20060623203556m12008vhg3e>; Fri, 23 Jun 2006 20:35:57 +0000 From: "David Harrington" To: "'David T. Perkins'" , "'Robert Story'" Subject: RE: [Isms] #6: Are there are any wrinkles to coexistencewithSNMPv1/v2c/USM? Date: Fri, 23 Jun 2006 16:34:43 -0400 Message-ID: <1b4d01c69704$766b88a0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcXkrfpQpF9usNLJSv21kbVg+pwDySyQIehg X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, So, has anybody walked through proxy to see how it would work? I believe that the SSHSM is unaffected by proxy. The only part of the SNMP entity that knows proxy is happening is the registered proxy application. Can anybody show different? dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of David T. Perkins > Sent: Tuesday, November 08, 2005 4:46 PM > To: Robert Story > Cc: isms@ietf.org > Subject: Re: [Isms] #6: Are there are any wrinkles to > coexistencewithSNMPv1/v2c/USM? > > HI, > > In the past (which seems to repeat) when new SNMP technology is made > available, then it is implemented first in managed devices, and only > later in managers. And of course, there will always be managed > devices that will never be updated. > > So, I believe that it is required that the following be supported: > Manager<--SNMPv1,SNMPv2c,SNMPv3/USM-->PROXY<---SNMPv3/ISMS-->device > > On Tue, 8 Nov 2005, Robert Story wrote: > > > On Fri, 14 Oct 2005 12:48:37 -0700 Randy wrote: > > RP> Someone should think through how proxy would work, or > whether it would be > > RP> simpler to just say "don't do that". > > > > It would be simpler, but I don't think we should do that. I > can definitely > > envision people wanting to put an SSHSM enabled device > at/near the border of > > their network and have it proxy for their legacy v1/v2c/v3 > devices inside the > > network. > > > Regards, > /david t. perkins > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jun 23 17:54:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FttbE-0003YH-GA; Fri, 23 Jun 2006 17:54:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FttbD-0003YC-80 for isms@ietf.org; Fri, 23 Jun 2006 17:53:59 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FttbC-0007HG-10 for isms@ietf.org; Fri, 23 Jun 2006 17:53:59 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (sccrmhc13) with SMTP id <2006062321535701300mhs6ie>; Fri, 23 Jun 2006 21:53:57 +0000 From: "David B Harrington" To: Date: Fri, 23 Jun 2006 17:52:44 -0400 Message-ID: <000c01c6970f$5ba5bd50$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaXDxxC2U1jxXk5QpOiIkJRzu02Lg== X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Subject: [Isms] FW: RADIUS integration X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org FYI. -----Original Message----- From: David Harrington [mailto:dharrington@huawei.com] Sent: Thursday, March 16, 2006 7:50 PM To: 'Kaushik Narayan (kaushik)'; 'Nelson, David'; j.schoenwaelder@iu-bremen.de Cc: 'Juergen Quittek'; 'Joseph Salowey (jsalowey)' Subject: RADIUS integration Hi, A private question came up about the RADIUS integration that was discussed at the interim. Since others may have different recollections, and many in the WG may not understand from the minutes what was discussed, I want to provide an overview of the interim-recommended approach on the mailing list. Q: Should the RADIUS integration be specific to SSHSM or can it apply to all transport-mapping security models? My understanding of the architectural positioning of the RADIUS piece that we discussed during the interim is that it is independent of the protocol used to provide authentication. The SNMP engine says to the RADIUS server "I assert that this principal has already been authenticated by other means. Please tell us what he is authorized to do." Obviously, the RADIUS server must trust the snmp engine as authentic. Effectively, this is a new authentication "mechanism" for RADIUS. The reason this was discussed is that many administrators prefer to use Kerberos or other authentication mechanisms, while still using RADIUS (or other service) to determine the authorizations for a principal. This separation of authentication and authorization is an important principal in SNMPv3. SNMPv2 bound them together, but the SNMPv3 WG separated them and provided securityName as the model-independent binding. The discussions at the interim placed the RADIUS (or other) authorization mechanism as an optional piece in an Access control model (or maybe the access control subsystem). It should have no dependencies on or place any dependencies on modules in the applications, the dispatcher, the messaging subsystem, the security subsystem, or the transport mapping, other than the model-independent parameters (e.g. securityName) that flow between subsystems through the ASIs. Therefore, it would be inappropriate to develop a RADIUS integration with SSHSM, or even with TMSM, since it should also work when USM or a Kerberos security model provides the "already authenticated principal". David Harrington dharrington@huawei.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jun 23 17:54:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FttbG-0003ZC-Jp; Fri, 23 Jun 2006 17:54:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FttbF-0003Ys-Cp for isms@ietf.org; Fri, 23 Jun 2006 17:54:01 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FttbE-0007HM-3b for isms@ietf.org; Fri, 23 Jun 2006 17:54:01 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (sccrmhc14) with SMTP id <2006062321535901400aquk8e>; Fri, 23 Jun 2006 21:53:59 +0000 From: "David Harrington" To: Subject: RE: [Isms] I-D ACTION:draft-narayan-isms-sshsm-radius-00.txt Date: Fri, 23 Jun 2006 17:52:44 -0400 Message-ID: <000d01c6970f$5cec4710$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaVboUuVWLn1cZKQp2HBpC0Tl4oOgBmcmUw In-reply-to: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, I started to read this draft. Unfortunately, this is not what was supposed to be written. The consensus was that we wanted an "authorize-only" RADIUS extension, to make RADIUS authorization independent of the authentication phase. The authorize-only should be accessible from the access control subsystem; the rest of the SNMP engine knows nothing about this RADIUS support for data access control (e.g. VACM). We explicitly did not want a RADIUS integration with SSHSM because that would violate the RFC3411 modularity and its separation of authentication and authorization. 1) If an operator wants RADIUS integration with SSH, that happens outside the SNMP engine. SSHSM and other security models should not need to know that SSH used RADIUS to authorize a session of SNMP management. 2) If an operator wants to use RADIUS to determine which VACM group to use for this user, that is handled strictly within the access control subsystem, using an authorize-only RADIUS extension, independently of the authentication provided via a security model, such as USM or SSHSM or USM/Kerberos. Some operators want to authenticate their users with Kerberos, but then as a separate step ask RADIUS what data access control policies to apply to that user. The interim meeting requirements for an authorize-only RADIUS extension was recapped in a mail message dated 3/16/06. dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, June 21, 2006 3:50 PM > To: i-d-announce@ietf.org > Subject: [Isms] I-D ACTION:draft-narayan-isms-sshsm-radius-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : RADIUS Usage for SNMP SSH Security Model > Author(s) : K. Narayan, D. Nelson > Filename : draft-narayan-isms-sshsm-radius-00.txt > Pages : 12 > Date : 2006-6-21 > > The Secure Shell Security Model (SSHSM) describes a Security Model > for the Simple Network Management Protocol, using the Secure Shell > protocol within a Transport Mapping. This memo describes the usage > of the Secure Shell Security Model with a RADIUS authentication and > authorization system. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-narayan-isms-sshsm-r > adius-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-narayan-isms-sshsm-radius-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-narayan-isms-sshsm-radius-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jun 23 18:08:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fttor-0007y8-GK; Fri, 23 Jun 2006 18:08:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fttoq-0007y3-EY for isms@ietf.org; Fri, 23 Jun 2006 18:08:04 -0400 Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fttop-0000CS-53 for isms@ietf.org; Fri, 23 Jun 2006 18:08:04 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id CFF4A11D5AC; Fri, 23 Jun 2006 15:07:59 -0700 (PDT) From: Wes Hardaker To: "David B Harrington" Subject: Re: [Isms] Name change Organization: Sparta References: <11bf01c69402$a99f6980$0400a8c0@china.huawei.com> Date: Fri, 23 Jun 2006 15:07:59 -0700 In-Reply-To: <11bf01c69402$a99f6980$0400a8c0@china.huawei.com> (David B. Harrington's message of "Mon, 19 Jun 2006 20:44:17 -0400") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org >>>>> On Mon, 19 Jun 2006 20:44:17 -0400, "David B Harrington" said: David> Would anybody object to my changing tmStateReference to David> tmSessionReference or simply sessionReference in both documents? The state reference in the USM doc captures data, for example, as it flows through the SM, through the agent and back out again and is then discarded after processing a single message. The concept of a "session" is much longer lived (and I'd expect the state data of the engine processing something to maybe cache a reference to the longer-lived session data). So... I'd change it if it is being discussed as a long lived set of data that is independent of the current processing. But I wouldn't change it if you're referring to state data that's used when processing a single message. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jun 23 18:20:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftu1A-0007Qc-W8; Fri, 23 Jun 2006 18:20:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftu1A-0007J6-8n for isms@ietf.org; Fri, 23 Jun 2006 18:20:48 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftu14-0001d7-V8 for isms@ietf.org; Fri, 23 Jun 2006 18:20:48 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 18:20:40 -0400 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] FW: RADIUS integration Date: Fri, 23 Jun 2006 18:20:40 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602192DA@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] FW: RADIUS integration Thread-Index: AcaXDxxC2U1jxXk5QpOiIkJRzu02LgAAPnKQ From: "Nelson, David" To: X-OriginalArrivalTime: 23 Jun 2006 22:20:40.0959 (UTC) FILETIME=[42EC40F0:01C69713] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org David Harrington writes... =20 > FYI. I've forgotten how I replied to the original message. =20 > Q: Should the RADIUS integration be specific to SSHSM or can it apply > to all transport-mapping security models? It is possible that it could apply to all transport-mapping security models, but it would take some additional analysis to be sure. =20 > My understanding of the architectural positioning of the RADIUS piece > that we discussed during the interim is that it is independent of the > protocol used to provide authentication. That was the expressed preference. It has not been determined that RADIUS can (should) be used in that fashion. That is the subject of ongoing study. Today, RADIUS is defined to provide separate authorization services only when the original authentication was via RADIUS and the RADIUS client and server share a state cookie. > The SNMP engine says to the > RADIUS server "I assert that this principal has already been > authenticated by other means. Please tell us what he is authorized to > do." Obviously, the RADIUS server must trust the snmp engine as > authentic. Effectively, this is a new authentication "mechanism" for > RADIUS. The trust model is one issue and the new authentication mechanism is a second issue. Given the desire to re-use existing RADIUS infrastructure to a large extent, the changes to RADIUS severs should be limited to new attributes that could be enrolled in a data dictionary. > The discussions at the interim placed the RADIUS (or other) > authorization mechanism as an optional piece in an Access control > model (or maybe the access control subsystem). Yes. > It should have no dependencies on or place any dependencies on=20 > modules in the applications, the dispatcher, the messaging subsystem, > the security subsystem, or the transport mapping, other than the > model-independent parameters (e.g. securityName) that flow between > subsystems through the ASIs. Nice sentiment. It would be helpful if ISMS would formalize this requirement for a new RADIUS "null" authentication mechanism, using an asserted identity and the trust relationship between the RADIUS client and server, together with an "authorize only" type of service request, in a formal document to the RADEXT WG. This is an action item out of the Boston Interim Meeting, as I recall. I did not undertake this action item, because of my position as a co-chair of RADEXT. I think that the requirement should come from the ISMS WG chairs. =20 > Therefore, it would be inappropriate to develop a RADIUS integration > with SSHSM, or even with TMSM, since it should also work when USM or a > Kerberos security model provides the "already authenticated > principal". We might be able to do this. If you want to maintain the full degree of modularity you will need to, but there is some considerable work to do on the RADIUS side to achieve this goal. I think we have a trade off to make between re-using existing AAA infrastructures and maintaining the traditional level of modularity and functional independence of SNMP. While there are undoubtedly a number of customers that want to use one service for authentication and another service for authorization, it is not clear to me that the original survey respondents who asked for integration with RADIUS had this in mind. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jun 23 18:30:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtuAC-0001wU-UJ; Fri, 23 Jun 2006 18:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtuAB-0001wP-7z for isms@ietf.org; Fri, 23 Jun 2006 18:30:07 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtuA9-0005Bh-W4 for isms@ietf.org; Fri, 23 Jun 2006 18:30:07 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (sccrmhc13) with SMTP id <2006062322300501300mjgn0e>; Fri, 23 Jun 2006 22:30:05 +0000 From: "David Harrington" To: "'Wes Hardaker'" , "'David B Harrington'" Subject: RE: [Isms] Name change Date: Fri, 23 Jun 2006 18:28:52 -0400 Message-ID: <001701c69714$67e9bf30$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaXEYBWWB5iWIutTkaI5CbW8/0TTgAACSDw In-reply-to: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi Wes, Yes. securityStateReference is per-message, and used to ensure that a response message with identical credentials can be generated even if the credentials in the LCD have been modified by the request. tmStateReference is about session information (assuming a session-based TM), and is thus longer lived. The document discusses this difference because there is a notion of cache release that must be handled differently for the long-lived session data than for the per-message data. I would like to change tmStateReference to tmSessionReference so it is easier to understand what is being cached at the other end of a tmSessionReference, rather than some "State" reference.. dbh > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > Sent: Friday, June 23, 2006 6:08 PM > To: David B Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] Name change > > >>>>> On Mon, 19 Jun 2006 20:44:17 -0400, "David B > Harrington" said: > > David> Would anybody object to my changing tmStateReference to > David> tmSessionReference or simply sessionReference in both > documents? > > The state reference in the USM doc captures data, for example, as it > flows through the SM, through the agent and back out again and is then > discarded after processing a single message. The concept of a > "session" is much longer lived (and I'd expect the state data of the > engine processing something to maybe cache a reference to the > longer-lived session data). > > So... I'd change it if it is being discussed as a long lived set of > data that is independent of the current processing. But I wouldn't > change it if you're referring to state data that's used when > processing > a single message. > -- > Wes Hardaker > Sparta, Inc. > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jun 23 18:38:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtuIc-00014I-Lm; Fri, 23 Jun 2006 18:38:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtuIb-0000ya-74 for isms@ietf.org; Fri, 23 Jun 2006 18:38:49 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtuIV-0007N4-Vs for isms@ietf.org; Fri, 23 Jun 2006 18:38:49 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 18:38:43 -0400 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] FW: RADIUS integration Date: Fri, 23 Jun 2006 18:38:43 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602192DB@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] FW: RADIUS integration Thread-Index: AcaXDxxC2U1jxXk5QpOiIkJRzu02LgABfZuA From: "Nelson, David" To: X-OriginalArrivalTime: 23 Jun 2006 22:38:43.0401 (UTC) FILETIME=[C81BCB90:01C69715] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org David Harrington writes... > The SNMP engine says to the > RADIUS server "I assert that this principal has already been > authenticated by other means. Please tell us what he is authorized to > do."=20 One of the things that the RADIUS server might very likely want to tell the SNMP engine is whether or not the authenticated user is allowed to manage devices using SNMP. If the answer is "no" then the established session gets dropped. With USM, the act of authenticating the user via the local USM data store implicitly authorizes the user to use SNMPv3. We don't know what access control would be applied, of course. In that regard, authorization of access controls would be similar in USM and TMSM. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jun 23 19:05:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftuij-0004t5-Dx; Fri, 23 Jun 2006 19:05:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftuih-0004sx-VQ for isms@ietf.org; Fri, 23 Jun 2006 19:05:47 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftuic-0000Ip-Kr for isms@ietf.org; Fri, 23 Jun 2006 19:05:47 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jun 2006 19:05:41 -0400 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] I-D ACTION:draft-narayan-isms-sshsm-radius-00.txt Date: Fri, 23 Jun 2006 19:05:41 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602192DC@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] I-D ACTION:draft-narayan-isms-sshsm-radius-00.txt Thread-Index: AcaVboUuVWLn1cZKQp2HBpC0Tl4oOgBmcmUwAAOKV4A= From: "Nelson, David" To: X-OriginalArrivalTime: 23 Jun 2006 23:05:41.0495 (UTC) FILETIME=[8C915870:01C69719] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org David Harrington writes... > I started to read this draft. Unfortunately, this is not what was > supposed to be written. That is one opinion. > The consensus was that we wanted an "authorize-only" RADIUS extension, > to make RADIUS authorization independent of the authentication phase. The consensus was that would be a preferred, but optional, feature it if fit within the RADIUS architecture. It is not clear that it does, although that avenue has not been fully explored. RADIUS by design tightly couples authentication and authorization. There is a limited form of "authorize only" service already defined that relies on a previous RADIUS authentication. We may be able to extend RADIUS to provide an autonomous authorization service, independent of authentication. That changes some fundamental assumptions in RADIUS, and would likely result in a change to RADIUS server implementations that could not be implemented simply by means of adding new attributes to a data dictionary. This has yet to be fully analyzed, however. > The authorize-only should be accessible from the access control > subsystem; the rest of the SNMP engine knows nothing about this RADIUS > support for data access control (e.g. VACM). We explicitly did not > want a RADIUS integration with SSHSM because that would violate the > RFC3411 modularity and its separation of authentication and > authorization. As I've said in another note, you may be able to satisfy this goal and you may not. Especially if re-use of existing AAA infrastructure is a critical factor. > 1) If an operator wants RADIUS integration with SSH, that happens > outside the SNMP engine. SSHSM and other security models should not > need to know that SSH used RADIUS to authorize a session of SNMP > management. I think this is incorrect or at least incomplete. Here's why. SSH/RADIUS integration today does not typically take into account whether or not an authenticated user is authorized to use a particular service, such as SNMP. This is not a problem when SSH is using separate RADIUS servers that are limited to authenticating and authorizing management access to network devices. In a single-sign-on environment, the fact that you can authenticate to log onto a PC or workstation does not mean you should be able to log on to manage network infrastructure devices. With USM, authentication and authorization aren't so entirely separate as you claim. The fact that a username and key are in the local USM store are implicit authorization that the user is allowed access to the SNMP engine. With general AAA systems like RADIUS there may be lots of users that can authenticate (e.g. for other purposes, like logging onto workstations) who should not be allowed to connect to an SNMP engine. > 2) If an operator wants to use RADIUS to determine which VACM group to > use for this user, that is handled strictly within the access control > subsystem, using an authorize-only RADIUS extension, independently of > the authentication provided via a security model, such as USM or SSHSM > or USM/Kerberos. That is a nice model, and may be achievable, if we can extend RADIUS to operate in that mode. It does not do so today. Initial discussion of adding that mode of operation on the RADEXT WG mailing list met with some push-back. Further work needs to be done here. > Some operators want to authenticate their users with > Kerberos, but then as a separate step ask RADIUS what data access > control policies to apply to that user. I'm sure that's true. > The interim meeting requirements for an authorize-only RADIUS > extension was recapped in a mail message dated 3/16/06. Yes, but it was *not* a requirement. It was a nice to have. That doesn't mean we should give up too easily on achieving this goal. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jun 23 19:37:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtvCu-0007hR-Dj; Fri, 23 Jun 2006 19:37:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtvCt-0007hM-N9 for isms@ietf.org; Fri, 23 Jun 2006 19:36:59 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtvCs-0001I9-HE for isms@ietf.org; Fri, 23 Jun 2006 19:36:59 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (sccrmhc14) with SMTP id <2006062323365801400aqnbme>; Fri, 23 Jun 2006 23:36:58 +0000 From: "David B Harrington" To: Date: Fri, 23 Jun 2006 19:35:44 -0400 Message-ID: <002e01c6971d$bf7c06a0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaXHaccl5viczWNTieIanRw0FLK2Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Isms] New drafts X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi I just submitted updates to TMSM and SSHSM documents to include the comments made earlier. The update to SSHSM is minor, but helps to make TMSM and SSHSM more in sync. David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jun 24 00:57:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu0DG-0002XZ-E8; Sat, 24 Jun 2006 00:57:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu0DF-0002TS-CL for isms@ietf.org; Sat, 24 Jun 2006 00:57:41 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu0DB-0006HZ-1e for isms@ietf.org; Sat, 24 Jun 2006 00:57:41 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1276C55E5B; Sat, 24 Jun 2006 06:57:36 +0200 (CEST) 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 32106-10; Sat, 24 Jun 2006 06:57:33 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 5999B55BC8; Sat, 24 Jun 2006 06:57:33 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 3541E75FD52; Sat, 24 Jun 2006 06:57:32 +0200 (CEST) Date: Sat, 24 Jun 2006 06:57:31 +0200 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] Name change Message-ID: <20060624045731.GA6432@noname> Mail-Followup-To: David B Harrington , isms@ietf.org References: <11bf01c69402$a99f6980$0400a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11bf01c69402$a99f6980$0400a8c0@china.huawei.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Mon, Jun 19, 2006 at 08:44:17PM -0400, David B Harrington wrote: > Would anybody object to my changing tmStateReference to > tmSessionReference or simply sessionReference in both documents? Is the assumption correct that every transport mapping security model will have a notion of a session? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Jun 24 09:06:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu7qY-0001Jr-64; Sat, 24 Jun 2006 09:06:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu7qX-0001Jm-01 for isms@ietf.org; Sat, 24 Jun 2006 09:06:45 -0400 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu7qR-0005lf-NY for isms@ietf.org; Sat, 24 Jun 2006 09:06:44 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (sccrmhc11) with SMTP id <2006062413063901100eqa7ee>; Sat, 24 Jun 2006 13:06:39 +0000 From: "David B Harrington" To: Subject: RE: [Isms] Name change Date: Sat, 24 Jun 2006 09:05:26 -0400 Message-ID: <007401c6978e$dcab4580$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaXSrZjs39JAflySOCfzfhnC6oNNwAQlC0w In-reply-to: <20060624045731.GA6432@noname> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, No, and yes. We discussed this at IETF65, where I had been requested to change some text that said everything MUST be session-based. I disagreed because it was possible some security model might be designed that did not have a session as such, so I disagreed that the texst should be changed that way. However, I do think that 99% of the protocols that might be used will be session-based, all the existing IETF protocols that might be used to provide a lower-layer secure transport are session-based, and those that are not could be cast into a session concept. USM could be described as having a session, but the session is short-lived (i.e the length of time it takes to process a request and response pair) or it is a long-lived "session" (that lasts as long as both sides are configured with the same shared keys). For practical considerations, it is likely that every TMSM will be session-based, and tmSessionReference is more meaningful than tmStateReference. I made the change in the two latest revisions of the documents. Let me know if I need to change it back. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Saturday, June 24, 2006 12:58 AM > To: David B Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] Name change > > On Mon, Jun 19, 2006 at 08:44:17PM -0400, David B Harrington wrote: > > > Would anybody object to my changing tmStateReference to > > tmSessionReference or simply sessionReference in both documents? > > Is the assumption correct that every transport mapping security model > will have a notion of a session? > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jun 26 11:46:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutIZ-0004mI-C2; Mon, 26 Jun 2006 11:46:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutIY-0004mA-Fq for isms@ietf.org; Mon, 26 Jun 2006 11:46:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FusKL-0006pb-4k for isms@ietf.org; Mon, 26 Jun 2006 10:44:37 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fus7J-0007ct-8r for isms@ietf.org; Mon, 26 Jun 2006 10:31:13 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 10:31:05 -0400 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] I-D ACTION:draft-narayan-isms-sshsm-radius-00.txt Date: Mon, 26 Jun 2006 10:31:05 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602192E3@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] I-D ACTION:draft-narayan-isms-sshsm-radius-00.txt Thread-Index: AcaVboUuVWLn1cZKQp2HBpC0Tl4oOgBmcmUwAIiMKDA= From: "Nelson, David" To: "David Harrington" , X-OriginalArrivalTime: 26 Jun 2006 14:31:05.0321 (UTC) FILETIME=[282C5590:01C6992D] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org > The consensus was that we wanted an "authorize-only" RADIUS extension, > to make RADIUS authorization independent of the authentication phase. Let me approach this issue from another angle. Along the continuum of WG goals, ranging from the unattainable "no new software versions required" to the annoying "you need an upgrade to everything", there are some interesting points to consider. Everyone agrees that new SNMP software (manager and agent) will be required to implement SSHSM. There is a desire to leverage, but not impact, the existing AAA infrastructures in wide deployment. There are four levels of potential impact that the ISMS works could have on RADIUS servers: 1. None at all. The ISMS work simply uses existing facilities as they exist in the field. 2. New attributes are needed that can simply be added to a data dictionary file. No new software version is required. 3. New attributes are needed and require a software version upgrade to implement. (This is distinguished from (3) by the server implementation.) 4. A new authentication method is needed and requires a software version upgrade. I think the mandatory to document (and implement) levels are (1) and (2). The optional to implement levels are (3) and (4), which are closely related. I believe that "consensus" you speak of includes at least levels (3) and (4). The draft that we just submitted addresses (1) and (2), and glosses over (3) and (4). The authors recognize the desire to effectively address these remaining issues, and will work to do so. However, I see the current draft text as necessary to address the base requirement for low impact integration methods. I believe that there is likely to be a similar range of levels of impact to the RADIUS client. As this is co-resident with the SNMP agent in most implementations, this may or may not be a concern. Certainly the level (1), no changes case would allow the RADIUS client to remain unmodified. There are unique deployment caveats and security considerations that attach to the no change case, however. Does this make any sense? Comments, please. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jun 26 12:39:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuu7p-0007lN-DD; Mon, 26 Jun 2006 12:39:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuu7o-0007e9-4a for isms@ietf.org; Mon, 26 Jun 2006 12:39:48 -0400 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuu7l-0007c8-NO for isms@ietf.org; Mon, 26 Jun 2006 12:39:48 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc12) with SMTP id <20060626163944m120095a3me>; Mon, 26 Jun 2006 16:39:44 +0000 From: "David Harrington" To: "'Nelson, David'" , Subject: RE: [Isms] I-D ACTION:draft-narayan-isms-sshsm-radius-00.txt Date: Mon, 26 Jun 2006 12:38:30 -0400 Message-ID: <007701c6993e$f5c0c070$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaVboUuVWLn1cZKQp2HBpC0Tl4oOgBmcmUwAIiMKDAAAre34A== In-Reply-To: <3CFB564E055A594B82C4FE89D21565602192E3@MABOSEVS2.ets.enterasys.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, There are basically two ways to use RADIUS with an SNMP engine. The first is a relationship between RADIUS and SSH. The WG has reached consensus that SSHSM should NOT be aware of the authentication mechanisms used by SSH. It should not matter to SSHSM whether SSH uses user/password, X.509, GSSAP, or RADIUS to authenticate the SSH client. The decision to use a RADIUS backend is a configuration decision of the deployer, and the configuration necessary depends on the SSH and RADIUS implementations used. The relationship between SSH and RADIUS at the lower layer should not be visible to SSHSM. Therefore, the impact that SSHSM has on RADIUS servers should be your 1) or 2), and the impact that using RADIUS to authenticate the SSH client has on SSHSM should be "none at all". That deals with one usage of RADIUS for SNMP. This interaction is between SSH and RADIUS and should be totally independent of SSHSM. In fact, the usage of RADIUS should not necessarily be dependent on SSH, but might be dependent in exactly the same way if we were to use a TLS lower layer that used RADIUS for authentication, or a BEEP lower layer that used RADIUS for authentication. The SNMP transport model and the SNMP security model should not care whether the lower layer outsources the decision to a centralized RADIUS server. Usage #1: A B +--------+ +--------+ | RADIUS |---------| SSH | | Server | | Client | +--------+ +--------+ The other usage deals with a relationship between an SNMP access control model, like VACM, and RADIUS. In this case, VACM (or its encompassing ACM subsystem) talks directly to RADIUS to determine the VACM (or other) configuration, such as Groupname to associate with the known security-model-independent securityName. This interaction between VACM (or other ACM model) is totally independent of SSHSM (or other security models). This usage should not care whether SSH or TLS or UDP is used as the transport for SNMP messages, and should not care whether the SNMP security model is SSHSM or USM or some other model. Usage #2: A B +--------+ +--------+ | RADIUS |---------| VACM | | Server | | Model | +--------+ +--------+ So there are two different usages that could be described, and if the WG wants them documented here they should either be in separate documents or clearly described as two totally separate usages. SSHSM should not even be mentioned in your document, because the SNMP transport mapping, and the SNMP security model should be independent of both RADIUS usages. dbh > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Monday, June 26, 2006 10:31 AM > To: David Harrington; isms@ietf.org > Subject: RE: [Isms] I-D ACTION:draft-narayan-isms-sshsm-radius-00.txt > > > The consensus was that we wanted an "authorize-only" RADIUS > extension, > > to make RADIUS authorization independent of the > authentication phase. > > Let me approach this issue from another angle. > > Along the continuum of WG goals, ranging from the unattainable "no new > software versions required" to the annoying "you need an upgrade to > everything", there are some interesting points to consider. > > Everyone agrees that new SNMP software (manager and agent) will be > required to implement SSHSM. > > There is a desire to leverage, but not impact, the existing AAA > infrastructures in wide deployment. There are four levels of > potential > impact that the ISMS works could have on RADIUS servers: > > 1. None at all. The ISMS work simply uses existing facilities as they > exist in the field. > > 2. New attributes are needed that can simply be added to a data > dictionary file. No new software version is required. > > 3. New attributes are needed and require a software version upgrade to > implement. (This is distinguished from (3) by the server > implementation.) > > 4. A new authentication method is needed and requires a > software version > upgrade. > > I think the mandatory to document (and implement) levels are (1) and > (2). The optional to implement levels are (3) and (4), which are > closely related. > > I believe that "consensus" you speak of includes at least > levels (3) and > (4). The draft that we just submitted addresses (1) and (2), and > glosses over (3) and (4). The authors recognize the desire to > effectively address these remaining issues, and will work to do so. > However, I see the current draft text as necessary to address the base > requirement for low impact integration methods. > > I believe that there is likely to be a similar range of > levels of impact > to the RADIUS client. As this is co-resident with the SNMP agent in > most implementations, this may or may not be a concern. Certainly the > level (1), no changes case would allow the RADIUS client to remain > unmodified. There are unique deployment caveats and security > considerations that attach to the no change case, however. > > Does this make any sense? Comments, please. > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jun 26 14:47:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuw7r-0001Jl-NL; Mon, 26 Jun 2006 14:47:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuw7q-0001Jg-D7 for isms@ietf.org; Mon, 26 Jun 2006 14:47:59 -0400 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuw7p-0001ME-4u for isms@ietf.org; Mon, 26 Jun 2006 14:47:58 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (rwcrmhc13) with SMTP id <20060626184755m13006n5c3e>; Mon, 26 Jun 2006 18:47:55 +0000 From: "David B Harrington" To: Date: Mon, 26 Jun 2006 14:46:41 -0400 Message-ID: <009201c69950$dde19620$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaZUGQLKf/SDYRuTCy1ubDt+yyITg== X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Isms] Separation of transport mapping from security model in SSHSM X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, Should we define a transport-mapping subsystem? This was not done in RFC3411. TMSM comes close to doing this, but doesn't go all the way. We could define a transport mapping extension to RFC3411, with ASI extensions showing a tmSessionReference (or tmStateReference) passed between the transport mapping subsystem and the dispatcher, and between the dispatcher and messaging subsystem, and between messaging subsystem and the security subsystem. That represents the bulk of the work done in the TMSM document. Then we could define an SSH transport mapping that discusses how to open or close an SSH session, and how to prepare the tmSessionReference from SSH parameters. This would be greatly simplified by only dealing with it as a transport mapping, and separating it via ASIs from the security model. In draft-ietf-isms-sechell-04.txt (submitted but not yet announced), the MPSP processing appears to be independent of SSH. All the transport-specific processing seems to be done by the TMSP portion. The MPSP portion only extracts model-independent parameters from tmSessionReference. (This assertion should be double-checked by others to make sure I didn't miss anything.) I believe the SSHSM-MPSP could be turned into a security model that would work with SSH, TLS, BEEP and other transport mappings, assuming comparable processing assumptions (authPriv only, no use of the msgSecurityParameter fields, etc.). David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jun 26 17:08:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyJP-00087G-CX; Mon, 26 Jun 2006 17:08:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyJO-00083c-6b for isms@ietf.org; Mon, 26 Jun 2006 17:08:02 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuyJM-0007UU-Vx for isms@ietf.org; Mon, 26 Jun 2006 17:08:02 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k5QL7ugh028635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jun 2006 17:07:57 -0400 (EDT) Date: Mon, 26 Jun 2006 17:07:56 -0400 From: Jeffrey Hutzelman To: "Nelson, David" , isms@ietf.org Subject: RE: [Isms] FW: RADIUS integration Message-ID: <8697D5A5B01C6AEDBFE8B193@sirius.fac.cs.cmu.edu> In-Reply-To: <3CFB564E055A594B82C4FE89D21565602192DA@MABOSEVS2.ets.enterasys.com> References: <3CFB564E055A594B82C4FE89D21565602192DA@MABOSEVS2.ets.enterasys. com> Originator-Info: login-token=Mulberry:01PdF4r6c57SOJHPAwcE+oHtRDr9rEBfGqRqYUc1E=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Friday, June 23, 2006 06:20:40 PM -0400 "Nelson, David" wrote: > That was the expressed preference. It has not been determined that > RADIUS can (should) be used in that fashion. That is the subject of > ongoing study. Today, RADIUS is defined to provide separate > authorization services only when the original authentication was via > RADIUS and the RADIUS client and server share a state cookie. And that model is no longer sufficient. Authentication and authorization _are_ separate concepts, and people are beginning to recognize that and treat them separately. Authentication is no longer always about usernames and passwords, and some authentication methods do not lend themselves to authenticating to some entity other than the one you want to talk to. Whether it's SSHSM, an SSH login session, 802.1x, or PPP dialup, authentication may take place via a mechanism that is outside the RADIUS server's control. Once that happens, the application needs to make a decision as to whether to provide access and at what level, and RADIUS is an appropriate tool for that, even though it did not handle authentication. But it can only be used that way if a RADIUS client can say "this is the user's identity; tell me what I need to know to make an access decision". -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jun 26 17:17:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuySK-0006GQ-UO; Mon, 26 Jun 2006 17:17:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuySJ-0006GL-Tx for isms@ietf.org; Mon, 26 Jun 2006 17:17:15 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuySI-0007so-Lt for isms@ietf.org; Mon, 26 Jun 2006 17:17:15 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k5QLHCxr028854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jun 2006 17:17:12 -0400 (EDT) Date: Mon, 26 Jun 2006 17:17:12 -0400 From: Jeffrey Hutzelman To: "Nelson, David" , isms@ietf.org Subject: RE: [Isms] FW: RADIUS integration Message-ID: <44A70529322E55FEF10214D8@sirius.fac.cs.cmu.edu> In-Reply-To: <3CFB564E055A594B82C4FE89D21565602192DA@MABOSEVS2.ets.enterasys.com> References: <3CFB564E055A594B82C4FE89D21565602192DA@MABOSEVS2.ets.enterasys. com> Originator-Info: login-token=Mulberry:012JrYp0ICTRsk5VAoCxgIFm8MD9JfzlFFDwYMDho=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Friday, June 23, 2006 06:20:40 PM -0400 "Nelson, David" wrote: > We might be able to do this. If you want to maintain the full degree of > modularity you will need to, but there is some considerable work to do > on the RADIUS side to achieve this goal. I think we have a trade off to > make between re-using existing AAA infrastructures and maintaining the > traditional level of modularity and functional independence of SNMP. > > While there are undoubtedly a number of customers that want to use one > service for authentication and another service for authorization, it is > not clear to me that the original survey respondents who asked for > integration with RADIUS had this in mind. It is worth noting here that the entire motivation behind ISMS is allowing sites to reuse their existing authentication infrastructure with SNMP. I don't know who originally requested this feature or why, but I can tell you that as a site which has been using Kerberos authentication for nearly 15 years, we are uninterested in authorization schemes that don't work with Kerberos authentication. My dialup NAS's have used Kerberos authentication since late 1999, and they use TACACS+ for access control because RADIUS couldn't do what we needed, which was to provide access control and provisioning without being responsible for authentication. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jun 26 17:23:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyYk-0002Zv-Js; Mon, 26 Jun 2006 17:23:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuyYj-0002Yh-7d for isms@ietf.org; Mon, 26 Jun 2006 17:23:53 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuyYi-00083P-15 for isms@ietf.org; Mon, 26 Jun 2006 17:23:53 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k5QLNm2T029043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jun 2006 17:23:48 -0400 (EDT) Date: Mon, 26 Jun 2006 17:23:48 -0400 From: Jeffrey Hutzelman To: David B Harrington , isms@ietf.org Subject: Re: [Isms] Separation of transport mapping from security model in SSHSM Message-ID: <604C9E0154C03B3625542D46@sirius.fac.cs.cmu.edu> In-Reply-To: <009201c69950$dde19620$0400a8c0@china.huawei.com> References: <009201c69950$dde19620$0400a8c0@china.huawei.com> Originator-Info: login-token=Mulberry:01KuSzw5RMKDd2LytEXWLjMsFW6u6xGCyXWeEoYGQ=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Monday, June 26, 2006 02:46:41 PM -0400 David B Harrington wrote: > Should we define a transport-mapping subsystem? This was not done in > RFC3411. TMSM comes close to doing this, but doesn't go all the way. ... > I believe the SSHSM-MPSP could be turned into a security model that > would work with SSH, TLS, BEEP and other transport mappings, assuming > comparable processing assumptions (authPriv only, no use of the > msgSecurityParameter fields, etc.). Hm; that's an interesting question. To date, we've mostly been assuming that an SSH transport model and security mapping would be fairly tightly coupled to each other, at least in practice, and that the same would likely be true for other TMSM's. I agree that it may well be possible to define a more general security model which could be shared by mappings for a variety of transports which provide security features. I think this idea warrants further discussion. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jun 26 18:01:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuz8e-0001Bb-C0; Mon, 26 Jun 2006 18:01:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuz8d-0001BR-Po for isms@ietf.org; Mon, 26 Jun 2006 18:00:59 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuz8Y-0003no-Hm for isms@ietf.org; Mon, 26 Jun 2006 18:00:59 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 18:00:53 -0400 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] FW: RADIUS integration Date: Mon, 26 Jun 2006 18:00:53 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602192EA@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] FW: RADIUS integration Thread-Index: AcaZZJwFjgEEr3gdSFO3VxC0wad7GQABmGYA From: "Nelson, David" To: X-OriginalArrivalTime: 26 Jun 2006 22:00:53.0652 (UTC) FILETIME=[FE78D540:01C6996B] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Jeffrey Hutzelman writes... =20 > And that model is no longer sufficient. Well, I certainly see the limitations. Of course, RADIUS is a legacy protocol and the reason we're addressing it in ISMS is because of its wide deployment. > Authentication and authorization _are_ separate concepts,=20 > and people are beginning to recognize that and treat them > separately. Sure. The only question is what it would take to perform that "separation" in RADIUS. We've had an initial discussion of this issue on the RADEXT list, that resulted in some push-back. We will continue that discussion both on the list and at IETF-66. > But it can only be used that way if a RADIUS client can say=20 > "this is the user's identity; tell me what I need to know to > make an access decision". Right. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jun 26 18:05:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzCY-00066H-6g; Mon, 26 Jun 2006 18:05:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzCW-0005wH-If for isms@ietf.org; Mon, 26 Jun 2006 18:05:00 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuzCR-0004Pp-8K for isms@ietf.org; Mon, 26 Jun 2006 18:05:00 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 18:04:54 -0400 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] FW: RADIUS integration Date: Mon, 26 Jun 2006 18:04:53 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602192EB@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] FW: RADIUS integration Thread-Index: AcaZZeZEHa0BW10kQ8GUD7K+iz9lQAABiT4g From: "Nelson, David" To: X-OriginalArrivalTime: 26 Jun 2006 22:04:54.0172 (UTC) FILETIME=[8DD545C0:01C6996C] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Jeffrey Hutzelman writes... > I don't know who originally requested this feature or why, ... As I recall, it was you who requested this feature, at the ISMS Interim Meeting. :-) But I'm sure you're not alone. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jun 26 18:07:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzEZ-0000CS-SF; Mon, 26 Jun 2006 18:07:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzEZ-0000CN-Ia for isms@ietf.org; Mon, 26 Jun 2006 18:07:07 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuzEY-0004bz-Bz for isms@ietf.org; Mon, 26 Jun 2006 18:07:07 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k5QM74lA000113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jun 2006 18:07:04 -0400 (EDT) Date: Mon, 26 Jun 2006 18:07:04 -0400 From: Jeffrey Hutzelman To: "Nelson, David" , isms@ietf.org Subject: RE: [Isms] FW: RADIUS integration Message-ID: <0F97B8B5469DED4106C02C6E@sirius.fac.cs.cmu.edu> In-Reply-To: <3CFB564E055A594B82C4FE89D21565602192EA@MABOSEVS2.ets.enterasys.com> References: <3CFB564E055A594B82C4FE89D21565602192EA@MABOSEVS2.ets.enterasys. com> Originator-Info: login-token=Mulberry:01SIsFibLzev2U1n0Kewk1+N/9PLTPv361ADPufgs=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Monday, June 26, 2006 06:00:53 PM -0400 "Nelson, David" wrote: > Jeffrey Hutzelman writes... > >> And that model is no longer sufficient. > > Well, I certainly see the limitations. Of course, RADIUS is a legacy > protocol and the reason we're addressing it in ISMS is because of its > wide deployment. > >> Authentication and authorization _are_ separate concepts, >> and people are beginning to recognize that and treat them >> separately. > > Sure. The only question is what it would take to perform that > "separation" in RADIUS. We've had an initial discussion of this issue > on the RADEXT list, that resulted in some push-back. We will continue > that discussion both on the list and at IETF-66. Well, I'm happy to show up on the mailing list and try to make the point (unfortunately, I can't come to the WG meeting at IETF-66, as I'm chairing another meeting that session). I don't see this as an ISMS-specific feature; in fact, I'm much more likely to deploy it for other uses. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jun 26 18:10:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzHV-00014L-Jn; Mon, 26 Jun 2006 18:10:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuzHU-00014G-EZ for isms@ietf.org; Mon, 26 Jun 2006 18:10:08 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuzHT-0004mk-7u for isms@ietf.org; Mon, 26 Jun 2006 18:10:08 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k5QMA5l0000164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jun 2006 18:10:05 -0400 (EDT) Date: Mon, 26 Jun 2006 18:10:05 -0400 From: Jeffrey Hutzelman To: "Nelson, David" , isms@ietf.org Subject: RE: [Isms] FW: RADIUS integration Message-ID: <43E3839278B53B7AC00A1748@sirius.fac.cs.cmu.edu> In-Reply-To: <3CFB564E055A594B82C4FE89D21565602192EB@MABOSEVS2.ets.enterasys.com> References: <3CFB564E055A594B82C4FE89D21565602192EB@MABOSEVS2.ets.enterasys. com> Originator-Info: login-token=Mulberry:01FlKH7IC6/GBinf9tSdC3W63EvhedhgCDx7VRTNI=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Monday, June 26, 2006 06:04:53 PM -0400 "Nelson, David" wrote: > Jeffrey Hutzelman writes... > >> I don't know who originally requested this feature or why, ... > > As I recall, it was you who requested this feature, at the ISMS Interim > Meeting. :-) But I'm sure you're not alone. RADIUS integration was already on the agenda when I got there. It may well have been me who pushed the idea that that meant being able to use RADIUS for access control with non-password authentication, rather than just allowing it to serve as a backend for SSH password or keyboard-interactive userauth. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Jun 26 18:36:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuzgu-0001uG-77; Mon, 26 Jun 2006 18:36:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuzgs-0001kp-7K for isms@ietf.org; Mon, 26 Jun 2006 18:36:22 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuzgm-0006ZJ-Sc for isms@ietf.org; Mon, 26 Jun 2006 18:36:22 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jun 2006 18:36:15 -0400 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] I-D ACTION:draft-narayan-isms-sshsm-radius-00.txt Date: Mon, 26 Jun 2006 18:36:15 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602192EC@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] I-D ACTION:draft-narayan-isms-sshsm-radius-00.txt Thread-Index: AcaVboUuVWLn1cZKQp2HBpC0Tl4oOgBmcmUwAIiMKDAAAre34AAN0MQA From: "Nelson, David" To: X-OriginalArrivalTime: 26 Jun 2006 22:36:15.0511 (UTC) FILETIME=[EF32D270:01C69970] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org David Harrington writes... =20 > There are basically two ways to use RADIUS with an SNMP engine. I think there are probably three ways. > The first is a relationship between RADIUS and SSH. My question is whether this is really one "way" or two? If all the SSH server is doing is "pure" authentication, then what component is doing "base level" authorization? RADIUS is basically a service provisioning protocol. For example, the client says "Hey, here's Alice, and she wants access." The server responds "Oh, I know Alice. Start a Telnet session to host foo.example.com for her." That's a bit different from simply authenticating the user and delivering a default service, e.g. the CLI prompt of some OS shell. We have talked about authentication. We have talked about authorization to provide optional access control, e.g. VACM or some other method. It is clear that the SSH server performs the authentication. It is clear that the Access Control Module performs the "granular" authorization. What hasn't been answered to my satisfaction is which component or module decides that the user is authorized to "start" an SNMPv3 session to begin with (what I called the "base level" authorization)? I suppose this might logically be the responsibility of the SSH server. I don't think that SSH does this today, especially since the RADIUS attributes that describe this authorization don't exist, except in the RADIUS NAS-Management draft. Worrying about which VACM table entry to use, before you've even established that the user should be doing SNMP access at all, bothers me. Now, there is (at least) one way to solve this issue. If the authentication of the user implicitly provides the "base level" authorization to use SNMPv3 access to the managed entity, then we're all set. This is the way USM works today. This can be achieved with RADIUS (or any other AAA) if (and only if) the data base of users who can authenticate is limited to only those users authorized to gain SNMPv3 management access. In practical terms, this can easily be accomplished by having a separate RADIUS server (or servers) for the network management staff. No other employees would be in that data base. Some operators may configure their AAA infrastructure that way. A variation on this theme is when a single RADIUS server, which is used to authenticate all employees, uses some "hint" information in the RADIUS Access-Request message, together with group membership or other access rights in the user data base, to decide when the access should be granted and when it should be denied. For example, dnelson@enterasys.com might be granted access for PPTP service through a VPN gateway but denied access for SNMPv3 management of that same VPN gateway. All of this needs to be described, somewhere. =20 > The other usage deals with a relationship between an SNMP access > control model, like VACM, and RADIUS. In this case, VACM (or its > encompassing ACM subsystem) talks directly to RADIUS to determine the > VACM (or other) configuration, such as Groupname to associate with the > known security-model-independent securityName. I think we basically agree here, and that relationship needs to be clarified in the subject draft. Assuming that RADIUS can be modified to deliver the autonomous authorization service that is being requested, this should be easy. If it cannot, for some reason, then we need to decide what, if anything, is an acceptable second best. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jun 27 13:26:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHKm-0004SB-0p; Tue, 27 Jun 2006 13:26:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHKl-0004S6-I1 for isms@ietf.org; Tue, 27 Jun 2006 13:26:43 -0400 Received: from mga02.intel.com ([134.134.136.20] helo=orsmga101-1.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvHKj-0003Yu-3j for isms@ietf.org; Tue, 27 Jun 2006 13:26:43 -0400 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101-1.jf.intel.com with ESMTP; 27 Jun 2006 10:26:40 -0700 Received: from fmsmsx331.fm.intel.com (HELO fmsmsx331.amr.corp.intel.com) ([132.233.42.156]) by orsmga001.jf.intel.com with ESMTP; 27 Jun 2006 10:26:40 -0700 X-IronPort-AV: i="4.06,183,1149490800"; d="scan'208"; a="57442610:sNHT91068054" Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 10:26:35 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 10:26:35 -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] FW: RADIUS integration Date: Tue, 27 Jun 2006 13:26:18 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E70405639DC60@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] FW: RADIUS integration thread-index: AcaZZLoPXmss7B0dSaG9cNC7MAh+QQAqX04g From: "Blumenthal, Uri" To: "Jeffrey Hutzelman" , "Nelson, David" , X-OriginalArrivalTime: 27 Jun 2006 17:26:35.0065 (UTC) FILETIME=[D6CD8290:01C69A0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Jeffrey, Of course you are correct - but since RADIUS is an old protocol, and its implementations are equally old and very much entrenched - I do not know how practical would it be to attempt to enforce a cleaner model over it. After all, there is DIAMETER that was supposed to address shortcomings of RADIUS - and where is it? It may be that you'd have to authenticate twice - to the peer entity and then to RADIUS to receive authorization information. And yes it is ugly. -----Original Message----- From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 Sent: Monday, June 26, 2006 2:08 PM To: Nelson, David; isms@ietf.org Cc: Jeffrey Hutzelman Subject: RE: [Isms] FW: RADIUS integration On Friday, June 23, 2006 06:20:40 PM -0400 "Nelson, David"=20 wrote: > That was the expressed preference. It has not been determined that > RADIUS can (should) be used in that fashion. That is the subject of > ongoing study. Today, RADIUS is defined to provide separate > authorization services only when the original authentication was via > RADIUS and the RADIUS client and server share a state cookie. And that model is no longer sufficient. Authentication and authorization=20 _are_ separate concepts, and people are beginning to recognize that and=20 treat them separately. Authentication is no longer always about usernames=20 and passwords, and some authentication methods do not lend themselves to authenticating to some entity other than the one you want to talk to.=20 Whether it's SSHSM, an SSH login session, 802.1x, or PPP dialup,=20 authentication may take place via a mechanism that is outside the RADIUS server's control. Once that happens, the application needs to make a=20 decision as to whether to provide access and at what level, and RADIUS is=20 an appropriate tool for that, even though it did not handle authentication.=20 But it can only be used that way if a RADIUS client can say "this is the user's identity; tell me what I need to know to make an access decision". -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jun 27 13:48:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHfn-0002vo-QL; Tue, 27 Jun 2006 13:48:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHfm-0002ua-M2 for isms@ietf.org; Tue, 27 Jun 2006 13:48:26 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvHfl-0005cr-DL for isms@ietf.org; Tue, 27 Jun 2006 13:48:26 -0400 Received: from mariner.pc.cs.cmu.edu (MARINER.PC.CS.CMU.EDU [128.2.200.130]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k5RHmIbf022008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jun 2006 13:48:18 -0400 (EDT) Date: Tue, 27 Jun 2006 13:48:18 -0400 From: Jeffrey Hutzelman To: "Blumenthal, Uri" , "Nelson, David" , isms@ietf.org Subject: RE: [Isms] FW: RADIUS integration Message-ID: <2287A9983F73C1C6A89ADEF9@mariner.pc.cs.cmu.edu> In-Reply-To: <279DDDAFA85EC74C9300A0598E70405639DC60@hdsmsx412.amr.corp.intel.com> References: <279DDDAFA85EC74C9300A0598E70405639DC60@hdsmsx412.amr.corp.intel .com> Originator-Info: login-token=Mulberry:011AJ38D5q7GQgTe9xB4CnX2t0rhtbNvBBd6VVCoI=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Tuesday, June 27, 2006 01:26:18 PM -0400 "Blumenthal, Uri" wrote: > Of course you are correct - but since RADIUS is an old protocol, and its > implementations are equally old and very much entrenched - I do not know > how practical would it be to attempt to enforce a cleaner model over it. > After all, there is DIAMETER that was supposed to address shortcomings > of RADIUS - and where is it? DIAMETER was an attempt to replace RADIUS from scratch. Last time I went to an AAA working group meeting was in 2000. I was there because I was trying to help the author of a document on Kerberos authentication for DIAMETER to get it right. The working group seemed to be interested in spending its time designing a transport protocol. Maybe they still are. I'm not trying to "enforce a cleaner model". What RADIUS provides is an authentication backend and authorization and provisioning service for devices providing network access (or whatever). The model is already reasonably clean; IMHO its only major architectural wart is the insistence on conflating authentication with authorization. The RADUIS server doesn't provide any services to the end user; therefore, it doesn't need to authenticate the end user's identity except to be able to assert that identity to its client. I'm proposing a model in which the RADIUS client asserts the end user's identity to the server, instead of the other way around. This is a fairly straightforward extension. > It may be that you'd have to authenticate twice - to the peer entity and > then to RADIUS to receive authorization information. And yes it is ugly. RADIUS is supposed to be invisible to the end user. How do I get a Kerberos ticket for a service that I don't even know exists? Or are you suggesting that after I authenticate to the SSH server using GSS-krb5, which allowed me to avoid giving it my password, I then have to give it my password anyway to satisfy the RADIUS server? Worse, broken as that approach is, SSH can handle it, because the protocol is designed such that servers can require multiple authentications using different methods before a user is granted access. Most network access protocols don't work that way, so this doesn't help me with my PPP dialups or my wireless or my VPN. I suspect we're reaching the point where we should take this discussion out of ISMS and over to RADEXT instead. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jun 27 13:53:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHl4-000755-7N; Tue, 27 Jun 2006 13:53:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHl2-0006wR-Fu for isms@ietf.org; Tue, 27 Jun 2006 13:53:52 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvHkx-0006T3-6Y for isms@ietf.org; Tue, 27 Jun 2006 13:53:52 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 13:53:46 -0400 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] FW: RADIUS integration Date: Tue, 27 Jun 2006 13:53:46 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602192FD@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] FW: RADIUS integration Thread-Index: AcaaEeSlirUtP6GPRliGaNlaof+eBgAAF8Dw From: "Nelson, David" To: X-OriginalArrivalTime: 27 Jun 2006 17:53:46.0622 (UTC) FILETIME=[A34959E0:01C69A12] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Jeffrey Hutzelman writes... > I suspect we're reaching the point where we should take=20 > this discussion out of ISMS and over to RADEXT instead. I think that would be useful. I've "penciled-in" a discussion slot in the RADEXT WG session at IETF-66. The agenda is always quite full, so it would be really helpful to get some discussion going on the list prior to Montreal. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jun 27 13:55:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHmd-0007xF-Rq; Tue, 27 Jun 2006 13:55:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHmc-0007vK-SQ for isms@ietf.org; Tue, 27 Jun 2006 13:55:30 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvHmb-0006hL-Jb for isms@ietf.org; Tue, 27 Jun 2006 13:55:30 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (sccrmhc15) with SMTP id <2006062717552901500r85d6e>; Tue, 27 Jun 2006 17:55:29 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'Blumenthal, Uri'" , "'Nelson, David'" , Subject: RE: [Isms] FW: RADIUS integration Date: Tue, 27 Jun 2006 13:54:16 -0400 Message-ID: <023b01c69a12$b5113350$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcaaEeVfjwv/1a7UTfGV8CJwt/JU8gAAHm6A In-Reply-To: <2287A9983F73C1C6A89ADEF9@mariner.pc.cs.cmu.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, The ISMS WG is supposed to prepare a request for RADEXT, explaining the requirements we would like to see addressesd, so this discussion may be in the right place. We just need to make sure we actually generate a request from ISMS to RADEXT, or the discussion is wasted. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Tuesday, June 27, 2006 1:48 PM > To: Blumenthal, Uri; Nelson, David; isms@ietf.org > Cc: Jeffrey Hutzelman > Subject: RE: [Isms] FW: RADIUS integration > > > > On Tuesday, June 27, 2006 01:26:18 PM -0400 "Blumenthal, Uri" > wrote: > > > Of course you are correct - but since RADIUS is an old > protocol, and its > > implementations are equally old and very much entrenched - > I do not know > > how practical would it be to attempt to enforce a cleaner > model over it. > > After all, there is DIAMETER that was supposed to address > shortcomings > > of RADIUS - and where is it? > > DIAMETER was an attempt to replace RADIUS from scratch. Last > time I went > to an AAA working group meeting was in 2000. I was there > because I was > trying to help the author of a document on Kerberos > authentication for > DIAMETER to get it right. The working group seemed to be > interested in > spending its time designing a transport protocol. Maybe they > still are. > > I'm not trying to "enforce a cleaner model". What RADIUS > provides is an > authentication backend and authorization and provisioning service for > devices providing network access (or whatever). The model is already > reasonably clean; IMHO its only major architectural wart is > the insistence > on conflating authentication with authorization. The RADUIS > server doesn't > provide any services to the end user; therefore, it doesn't need to > authenticate the end user's identity except to be able to assert that > identity to its client. > > I'm proposing a model in which the RADIUS client asserts the > end user's > identity to the server, instead of the other way around. > This is a fairly > straightforward extension. > > > > It may be that you'd have to authenticate twice - to the > peer entity and > > then to RADIUS to receive authorization information. And > yes it is ugly. > > RADIUS is supposed to be invisible to the end user. How do I get a > Kerberos ticket for a service that I don't even know exists? > Or are you > suggesting that after I authenticate to the SSH server using > GSS-krb5, > which allowed me to avoid giving it my password, I then have > to give it my > password anyway to satisfy the RADIUS server? > > Worse, broken as that approach is, SSH can handle it, because > the protocol > is designed such that servers can require multiple > authentications using > different methods before a user is granted access. Most > network access > protocols don't work that way, so this doesn't help me with > my PPP dialups > or my wireless or my VPN. > > > I suspect we're reaching the point where we should take this > discussion out > of ISMS and over to RADEXT instead. > > -- Jeff > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jun 27 14:08:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHyj-0007RP-8W; Tue, 27 Jun 2006 14:08:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvHyi-0007RJ-0j for isms@ietf.org; Tue, 27 Jun 2006 14:08:00 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvHyb-0007Bo-Nz for isms@ietf.org; Tue, 27 Jun 2006 14:07:59 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 14:07:53 -0400 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] FW: RADIUS integration Date: Tue, 27 Jun 2006 14:07:53 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565602192FE@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] FW: RADIUS integration Thread-Index: AcaaEeVfjwv/1a7UTfGV8CJwt/JU8gAAHm6AAAAuAUA= From: "Nelson, David" To: X-OriginalArrivalTime: 27 Jun 2006 18:07:53.0029 (UTC) FILETIME=[9BC8CF50:01C69A14] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org > The ISMS WG is supposed to prepare a request for RADEXT, explaining > the requirements we would like to see addressesd, so this discussion > may be in the right place. A simple e-mail message from the ISMS chairs would suffice. This doesn't need to be an I-D. Something like: The ISMS WG has a requirement for its use of RADIUS as a centralized AAA service to be used with SNMPv3 running over a protected transport, specifically over SSH. The requirement is for an "Authorize Only" service in RADIUS, in which the NAS asserts the identity of a user, previously authenticated to the NAS by some other authentication service, such as Kerberos. The RADIUS server is required to respond to the NAS with the appropriate authorization and service provisioning attributes for that user, including those specific to ISMS usages. It is desired to leverage existing RADIUS deployments, and thus the ISMS WG has a preference for RADIUS integration methods that require no change to RADIUS server implementations, or at most the enrollment of additional provisioning attributes in a data dictionary. New RADIUS operational modes that would require changes to existing RADIUS server implementations are less desirable, but could be considered. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jun 27 15:50:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJZd-0006GC-5N; Tue, 27 Jun 2006 15:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJZT-0005rD-Bc; Tue, 27 Jun 2006 15:50:03 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJZS-0001Nw-28; Tue, 27 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo19F012450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZR-0005FX-MY; Tue, 27 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-tmsm-03.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Mapping Security Model (TMSM) Architectural Extension for the Simple Network Management Protocol (SNMP) Author(s) : D. Harrington, J. Schoenwaelder Filename : draft-ietf-isms-tmsm-03.txt Pages : 47 Date : 2006-6-27 This document describes a Transport Mapping Security Model (TMSM) extension for the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document identifies and discusses some key aspects that need to be considered for any transport-mapping-based security model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-tmsm-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-tmsm-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27111348.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-tmsm-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-tmsm-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27111348.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Tue Jun 27 17:13:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKs2-0007OR-51; Tue, 27 Jun 2006 17:13:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvKs1-0007MP-3N; Tue, 27 Jun 2006 17:13:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJwS-0005Ox-3V; Tue, 27 Jun 2006 16:13:48 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvJaS-0003X9-Gs; Tue, 27 Jun 2006 15:51:08 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5RJo1jx016431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 19:50:04 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvJZR-0005Fd-Nj; Tue, 27 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 15:50:01 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-secshell-04.txt X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Secure Shell Security Model for SNMP Author(s) : J. Salowey, D. Harrington Filename : draft-ietf-isms-secshell-04.txt Pages : 48 Date : 2006-6-27 This memo describes a Security Model for the Simple Network Management Protocol, using the Secure Shell protocol within a Transport Mapping. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-secshell-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-secshell-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27111656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-secshell-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-secshell-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27111656.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@lists.ietf.org Tue Jun 27 18:11:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvLmX-0003x0-VW; Tue, 27 Jun 2006 18:11:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvLmW-0003wu-Fa for isms@ietf.org; Tue, 27 Jun 2006 18:11:40 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvLmV-00022Y-8g for isms@ietf.org; Tue, 27 Jun 2006 18:11:40 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k5RMBO0I029760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jun 2006 18:11:28 -0400 (EDT) Date: Tue, 27 Jun 2006 18:11:24 -0400 From: Jeffrey Hutzelman To: "Nelson, David" , isms@ietf.org Subject: RE: [Isms] FW: RADIUS integration Message-ID: In-Reply-To: <3CFB564E055A594B82C4FE89D21565602192FE@MABOSEVS2.ets.enterasys.com> References: <3CFB564E055A594B82C4FE89D21565602192FE@MABOSEVS2.ets.enterasys. com> Originator-Info: login-token=Mulberry:01+fxysmNk5yZFR+ozLHqiIZBuqd2AMOtmcaAXL3w=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Tuesday, June 27, 2006 02:07:53 PM -0400 "Nelson, David" wrote: > It is desired to leverage existing RADIUS deployments, and thus the ISMS > WG has a preference for RADIUS integration methods that require no > change to RADIUS server implementations, or at most the enrollment of > additional provisioning attributes in a data dictionary. New RADIUS > operational modes that would require changes to existing RADIUS server > implementations are less desirable, but could be considered. Except I don't think that's actually a requirement, and I do think it makes the solution considerably harder. I don't consider it unreasonable for people wanting to use the authorize-only feature to have to upgrade their RADIUS servers to support a new authentication method. I do think it is preferable for deployments not using the new feature not to require any changes to the RADIUS server code. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jun 27 18:32:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvM6F-0000Zp-EX; Tue, 27 Jun 2006 18:32:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvM6E-0000Zd-JT for isms@ietf.org; Tue, 27 Jun 2006 18:32:02 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvM69-0003eY-AU for isms@ietf.org; Tue, 27 Jun 2006 18:32:02 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 18:31:53 -0400 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] FW: RADIUS integration Date: Tue, 27 Jun 2006 18:31:52 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219308@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] FW: RADIUS integration Thread-Index: AcaaNqntzxZxfZLfTFSuMYc2D0TVhAAAFBbA From: "Nelson, David" To: X-OriginalArrivalTime: 27 Jun 2006 22:31:53.0052 (UTC) FILETIME=[7D2C81C0:01C69A39] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Jeffrey Hutzelman writes... > Except I don't think that's actually a requirement, and > I do think it makes the solution considerably harder. Well, I recall a *lot* of discussion early on about ISMS having a requirement to use *existing* AAA deployments. There was concern expressed that if these entrenched systems needed to be updated, that the ISMS work would never be deployed, and we'd all have wasted our time. But, see below... > I don't consider it unreasonable for people wanting to use > the authorize-only feature to have to upgrade their > RADIUS servers to support a new authentication method. I agree, as long as it's an option. Unless, of course, we can find a way to do this using only new attributes that can be enrolled in a data dictionary. In that case, no RADIUS server SW upgrade would be required. > I do think it is preferable for deployments not using the new feature not > to require any changes to the RADIUS server code. Right. So, how about this text: The ISMS WG has a requirement for its use of RADIUS as a centralized AAA service to be used with SNMPv3 running over a protected transport, specifically over SSH. Two operational modes are envisioned. In the first operational mode, the Access Control Module within the SNMP engine of the NAS will request of the RADIUS client an authentication of a remote SNMP user for the purpose of SNMPv3 access over SSH, with appropriate authorization and provisioning attributes, including those specific to ISMS usages. The RADIUS transaction will use an existing RADIUS authentication method, or possibly use the "Call-Check" pre-authentication mechanism. In the second mode of operation Access Control Module in the SNMP engine of the NAS will request an "Authorize Only" service from the RADIUS client. The requirement is for an "Authorize Only" service in RADIUS, in which the NAS asserts the identity of a user, previously authenticated to the NAS by some other authentication service, such as Kerberos. The RADIUS server is required to respond to the NAS with the appropriate authorization and service provisioning attributes for that user, including those specific to ISMS usages. It is desired to leverage existing RADIUS deployments, and thus the ISMS WG has a preference for RADIUS integration methods that require no change to RADIUS server implementations, or at most the enrollment of additional provisioning attributes in a data dictionary. New RADIUS operational modes that would require changes to existing RADIUS server implementations are less desirable, but would be considered for the "Authorize Only" mode of operation. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Jun 27 18:43:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMHb-0007pL-F8; Tue, 27 Jun 2006 18:43:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMHa-0007pG-FX for isms@ietf.org; Tue, 27 Jun 2006 18:43:46 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvMHZ-0004x6-8o for isms@ietf.org; Tue, 27 Jun 2006 18:43:46 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k5RMhaJS000360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jun 2006 18:43:37 -0400 (EDT) Date: Tue, 27 Jun 2006 18:43:36 -0400 From: Jeffrey Hutzelman To: "Nelson, David" , isms@ietf.org Subject: RE: [Isms] FW: RADIUS integration Message-ID: In-Reply-To: <3CFB564E055A594B82C4FE89D2156560219308@MABOSEVS2.ets.enterasys.com> References: <3CFB564E055A594B82C4FE89D2156560219308@MABOSEVS2.ets.enterasys. com> Originator-Info: login-token=Mulberry:01LvvM45hjQVd6RkRkYXn8UsVtAw61L0WbcPpIZHs=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Tuesday, June 27, 2006 06:31:52 PM -0400 "Nelson, David" wrote: > So, how about this text: > In the first operational mode, the Access Control Module within the SNMP > engine of the NAS will request of the RADIUS client an authentication of > a remote SNMP user for the purpose of SNMPv3 access over SSH, with > appropriate authorization and provisioning attributes, including those > specific to ISMS usages. The RADIUS transaction will use an existing > RADIUS authentication method, or possibly use the "Call-Check" > pre-authentication mechanism. This can't and won't happen in the ACM; it needs to happen in the SSH layer. Until a client has successfully authenticated to the SSH server, it can't do anything that would be visible to the SNMP engine. So, what we're really talking about in this scenario is (1) RADIUS as an authentication backend for SSH (2) what you called "base-level" authorization to use SNMP (3) optionally, additional data for fine-grained access control The data in step (3) would be used by the ACM, though getting it there might require a gross violation of modularity in the SNMP engine. Or, it might not. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 28 04:56:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvVqg-0003z6-2G; Wed, 28 Jun 2006 04:56:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvVq6-00037C-EI for isms@ietf.org; Wed, 28 Jun 2006 04:56:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvVNn-0002Pl-JP for isms@ietf.org; Wed, 28 Jun 2006 04:26:47 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvVKg-0001Ml-CA for isms@ietf.org; Wed, 28 Jun 2006 04:23:37 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Jun 2006 01:23:33 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5S8NXh4011602; Wed, 28 Jun 2006 01:23:33 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5S8NX9s002928; Wed, 28 Jun 2006 01:23:33 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp79.cisco.com [10.61.64.79]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k5S8ISor000662; Wed, 28 Jun 2006 01:18:28 -0700 Message-ID: <44A23C82.7060509@cisco.com> Date: Wed, 28 Jun 2006 10:23:30 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Jeffrey Hutzelman Subject: Re: [Isms] FW: RADIUS integration References: <3CFB564E055A594B82C4FE89D2156560219308@MABOSEVS2.ets.enterasys. com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-3.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=651; t=1151483013; x=1152347013; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Isms]=20FW=3A=20RADIUS=20integration; X=v=3Dcisco.com=3B=20h=3DLnpFq5Vjd8bh6N1YmT0cV64Ub3s=3D; b=LmR4J15S6VvrMfEGV5JG5OYylkyWbrQYTdnnUHu6S4Jm6MQPKYxp5EMrmbzNtsZWLF3MlgHU JfDERUOvTF3aJ+U0ucxslT/uFFOoZqrQplsgwL5yNML6/sEYVI/LHdpL; X-Spam-Score: -2.2 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Jeffrey Hutzelman wrote: > So, what we're really talking about in this scenario is > > (1) RADIUS as an authentication backend for SSH > (2) what you called "base-level" authorization to use SNMP > (3) optionally, additional data for fine-grained access control > > The data in step (3) would be used by the ACM, though getting it there > might require a gross violation of modularity in the SNMP engine. Or, > it might not. Two issues: - still need to maintain proper functional separation to s/radius/other/ - how do (2) and (3) interact, if at all? Are they mutually exclusive or implementation dependent? Thanks, Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 28 11:18:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvboM-0000Zs-4g; Wed, 28 Jun 2006 11:18:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvboK-0000Vl-Hi for isms@ietf.org; Wed, 28 Jun 2006 11:18:36 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvboF-0002Y3-9e for isms@ietf.org; Wed, 28 Jun 2006 11:18:36 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 11:18:30 -0400 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] FW: RADIUS integration Date: Wed, 28 Jun 2006 11:18:30 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021930B@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] FW: RADIUS integration Thread-Index: AcaaO0olXTtjoEy4RdqOI/VJNjx+5QAidgrQ From: "Nelson, David" To: X-OriginalArrivalTime: 28 Jun 2006 15:18:30.0983 (UTC) FILETIME=[1D256570:01C69AC6] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Jeffrey Hutzelman writes... > This can't and won't happen in the ACM; it needs to happen in the SSH > layer. Unless I'm mistaken, this is at variance with the recent posting from Dave Harrington. It appears that we need to have some further discussion on this point. > Until a client has successfully authenticated to the SSH server, > it can't do anything that would be visible to the SNMP engine. Yes, that's true. Did it appear from my description that the SNMP-driven authorization phase would occur before the SSH-driven authentication phase? =20 > So, what we're really talking about in this scenario is >=20 > (1) RADIUS as an authentication backend for SSH > (2) what you called "base-level" authorization to use SNMP > (3) optionally, additional data for fine-grained access control Yes, I think that's right. > The data in step (3) would be used by the ACM, though getting it there > might require a gross violation of modularity in the SNMP engine. Why do you think so? Is there anything in the SNMP architecture that precludes any of the modules from using a "system service", external to SNMP, such as AAA? Perhaps simply the fact that no such dependency is currently described? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 28 12:37:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvd31-0006Jq-Qj; Wed, 28 Jun 2006 12:37:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvd30-0006Fh-EQ for isms@ietf.org; Wed, 28 Jun 2006 12:37:50 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvd2y-0002EM-6P for isms@ietf.org; Wed, 28 Jun 2006 12:37:50 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k5SGbkaF019050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jun 2006 12:37:46 -0400 (EDT) Date: Wed, 28 Jun 2006 12:37:46 -0400 From: Jeffrey Hutzelman To: Eliot Lear Subject: Re: [Isms] FW: RADIUS integration Message-ID: In-Reply-To: <44A23C82.7060509@cisco.com> References: <3CFB564E055A594B82C4FE89D2156560219308@MABOSEVS2.ets.enterasys. com> <44A23C82.7060509@cisco.com> Originator-Info: login-token=Mulberry:01gxVAp+19tRvPYLgotpNwFhqHd9IKSbnwim4MuZU=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: isms@ietf.org, Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Wednesday, June 28, 2006 10:23:30 AM +0200 Eliot Lear wrote: > Jeffrey Hutzelman wrote: >> So, what we're really talking about in this scenario is >> >> (1) RADIUS as an authentication backend for SSH >> (2) what you called "base-level" authorization to use SNMP >> (3) optionally, additional data for fine-grained access control >> >> The data in step (3) would be used by the ACM, though getting it there >> might require a gross violation of modularity in the SNMP engine. Or, >> it might not. > > Two issues: > > - still need to maintain proper functional separation to s/radius/other/ Yes. Conceptually, it's the ssh server that decides whether to allow a client to establish a session and/or start SNMP, and it's VACM that decides which clients have what level of access to what objects. These decisions can be based partly or entirely on RADIUS, or not. Part of what we need to to is ensure that it's possible to use RADIUS to help make these decisions, even if it isn't used for authentication. Another part is probably to define a common set of RADIUS attributes that can be used to drive these decisions, at least for (2). I'm not sure if that's necessary or appropriate for (3), because I don't have a good idea of what kinds of authorization policies people have in place at that level. > - how do (2) and (3) interact, if at all? Are they mutually exclusive > or implementation dependent? Well, obviously if the answer is (2), you never get to (3). :-) Otherwise, I don't think they do interact, except that you might do both using attributes from the same RADIUS exchange, rather than performing a separate query for fine-grained access. We probably should make it clear in TMSM that an SNMP agent MAY cache authorization data (including RADIUS attributes) for the duration of a session. To the extent we talk about RADIUS, we probably want to make it clear that while SSH authentication and authorization are distinct and separate from VACM, it's OK for an implementation to cache RADIUS responses from the former for use in the latter. Now that I think about it, it seems like it's going to be necessary to have some way for the transport mapping to pass some amount of data through to VACM, in order to support the case where we don't use the hypothetical authorize-only RADIUS mode. That's either going to be cached RADIUS attributes, or some kind of cookie that can be used to make further queries to the server. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 28 12:45:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvdAg-0001mt-94; Wed, 28 Jun 2006 12:45:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvdAe-0001mn-QZ for isms@ietf.org; Wed, 28 Jun 2006 12:45:44 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvdAd-0002RB-JE for isms@ietf.org; Wed, 28 Jun 2006 12:45:44 -0400 Received: from sirius.fac.cs.cmu.edu (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k5SGjbqU019240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jun 2006 12:45:39 -0400 (EDT) Date: Wed, 28 Jun 2006 12:45:37 -0400 From: Jeffrey Hutzelman To: "Nelson, David" , isms@ietf.org Subject: RE: [Isms] FW: RADIUS integration Message-ID: <30C4DD888E6F3477C975C557@sirius.fac.cs.cmu.edu> In-Reply-To: <3CFB564E055A594B82C4FE89D215656021930B@MABOSEVS2.ets.enterasys.com> References: <3CFB564E055A594B82C4FE89D215656021930B@MABOSEVS2.ets.enterasys. com> Originator-Info: login-token=Mulberry:01x2IZbDHKjuATrZHt+uBJ217UUJdOlpI010fR/eI=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Jeffrey Hutzelman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Wednesday, June 28, 2006 11:18:30 AM -0400 "Nelson, David" wrote: > Jeffrey Hutzelman writes... > >> This can't and won't happen in the ACM; it needs to happen in the SSH >> layer. > > Unless I'm mistaken, this is at variance with the recent posting from > Dave Harrington. It appears that we need to have some further > discussion on this point. > >> Until a client has successfully authenticated to the SSH server, >> it can't do anything that would be visible to the SNMP engine. > > Yes, that's true. Did it appear from my description that the > SNMP-driven authorization phase would occur before the SSH-driven > authentication phase? Yes, because you made specific reference to the SNMP Access Control Module, which is responsible for authorization, but not authentication. >> So, what we're really talking about in this scenario is >> >> (1) RADIUS as an authentication backend for SSH >> (2) what you called "base-level" authorization to use SNMP >> (3) optionally, additional data for fine-grained access control > > Yes, I think that's right. > >> The data in step (3) would be used by the ACM, though getting it there >> might require a gross violation of modularity in the SNMP engine. > > Why do you think so? Because unless _I'm_ terribly confused, the ACM doesn't do authentication. So if you can only talk to the RADIUS server if you do authentication, or use some form of cookie resulting from successfuly authentication (I don't know such a thing exists, but your previous writings have led me to believe there must be something like that), then _something_ has to make its way from the module that did authentication to the one that's going to make access control decisions. Since SNMP has gone to a fair bit of trouble to define the abstractions between modules rather than leaving them up to the implementors, that information has to fit the abstraction. I wonder if maybe we have some sort of disconnect here. Maybe Dave H or one of the Juergen's can see what it is and tell us. -- Jeff _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 28 14:35:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvesz-0003cj-NA; Wed, 28 Jun 2006 14:35:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvesy-0003OG-2n for isms@ietf.org; Wed, 28 Jun 2006 14:35:36 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvesx-0004bR-Mu for isms@ietf.org; Wed, 28 Jun 2006 14:35:36 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (sccrmhc14) with SMTP id <20060628183524014008b9qoe>; Wed, 28 Jun 2006 18:35:24 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'Nelson, David'" , Date: Wed, 28 Jun 2006 14:34:10 -0400 Message-ID: <068601c69ae1$72d0e650$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acaa0k11bCjeNMeVRvG14uvtm3Bp6wAAhmPg In-Reply-To: <30C4DD888E6F3477C975C557@sirius.fac.cs.cmu.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: Subject: [Isms] SNMP "access control" terminology X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, I'll present my understanding of the RFCs and the intentions of the authors to clarify this. This message is about the term "access control" in SNMP. -- terminology -- Let me make sure we are all using similar terminology. I think that is a problem thus far. In RFC3411, we define subsystems and models. There is a subsystem for message handling, one for "security", one for applications, one for access control, one for applications, and we are proposing a subsystem for transport mapping. Each subsystem is allowed multiple models. (Note that there is only one dispatcher that coordinates between the subsystems, and there can be only one dispatcher "model" per RFC3411.) The messaging subsystem can support snmpv1, snmpv2c, and snmpv3 and future message versions. This subsystem is all about knowing how to create/extract the component parts of an an SNMP message - the global stuff, the version-speciifc stuff, the (opaque) securityParameters, and the scopedPDU. The security subsystem is designed to support models for USM, a community-based authentication approach, and other security models; the security subsystem is designed to handle message-related security, such as authentication, encryption, timeliness/replay, and message integrity. The application subsytem defines supported operations, and the details of how to perform them. Applications register themselves to be passed messages for specific contextEngines and specific operations types. The access control subsystem, the ACM, permits multiple models of access control. An access control model advises applications about who is allowed to do what operations to which objects in which subsets of data. The transport mapping subsystem handles the choice of port and transport. It probably should not be involved in making decisions about access to data (SNMP access control), message versions, or message-specific parameters, although that may need to be discussed further. -- SNMP traditionally has not worked with a session approach, so there is no concept of authorizing an snmp session in RFC3411. It has been argued that authentication via USM implies authorization to use SNMP at that engine. I believe that is incorrect. SNMPv3 has no concept that a user is "authorized" by USM to perform SNMP operations. For example, in an engine that only supports USM and VACM, "dbh" could have an entry in the usmUserTable, and I might be able to authenticate myself to an engine, but if VACM has no assignment for the securityName "dbh" to an authorized group, then I am not authorized to perform any SNMP operations on any objects in any contexts at that entity. It is the VACM access control subsystem that makes this determination, not the USM security model. So, when we talk about access control in SNMP, we really should restrict that terminology to refer to the functionality provided by the ACM subsystem. -- A little history: The processIncomingMsg() ASI lacks the parameters to pass the transportAddress information from an incoming message into the security model. Wonder why? It was not an oversight. During the discussions of SNMPv2 and SNMPv3 designs, there was a persistent request by operators for support of an approach frequently used as an authorization mechanism. This was the practice of only allowing certain IP addresses (e.g. from the NOC) to perform SNMP at a device. This was deliberately excluded from the design of SNMPv3. The authentication and the authorization aspects of that approach are much weaker than the authentication provided by USM and the authorization provided by VACM. SNMPv3 design exlicitly separates authentication of the principal, and authorization to perform SNMP operations. There is no authorization implied by the authentication of a principal. -- RADIUS has the ability to advise a server which services shoud be permitted when a client connects to a server. I think referring to this as "access control" within an SNMP engine will cause nothing but problems. The decision to permit access to an SSH subsytem called "snmp" is based on a transaction between a RADIUS advisor, and an SSH enforcer (or "snmp" service provider). SNMP does not enter into this decision at all. SNMP will never even see a message that comes to an SSH server, if the SSH server does not permit the "snmp" service. The decision to permit opening an SSH subsystem called "snmp" certainly does NOT happen in the security subsystem of an SNMP engine. The decision to close an existing subsystem at the advice of RADIUS should NOT happen in the ACM subsystem; it should happen only in the SSH server that provides the "snmp" service. Conclusion: let us not use the term "access control" to refer to the decision made by SSH to allow or reject a request for an "snmp" subsystem. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Wednesday, June 28, 2006 12:46 PM > To: Nelson, David; isms@ietf.org > Cc: Jeffrey Hutzelman > Subject: RE: [Isms] FW: RADIUS integration > > > > On Wednesday, June 28, 2006 11:18:30 AM -0400 "Nelson, David" > wrote: > > > Jeffrey Hutzelman writes... > > > >> This can't and won't happen in the ACM; it needs to happen > in the SSH > >> layer. > > > > Unless I'm mistaken, this is at variance with the recent > posting from > > Dave Harrington. It appears that we need to have some further > > discussion on this point. > > > >> Until a client has successfully authenticated to the SSH server, > >> it can't do anything that would be visible to the SNMP engine. > > > > Yes, that's true. Did it appear from my description that the > > SNMP-driven authorization phase would occur before the SSH-driven > > authentication phase? > > Yes, because you made specific reference to the SNMP Access > Control Module, > which is responsible for authorization, but not authentication. > > > > >> So, what we're really talking about in this scenario is > >> > >> (1) RADIUS as an authentication backend for SSH > >> (2) what you called "base-level" authorization to use SNMP > >> (3) optionally, additional data for fine-grained access control > > > > Yes, I think that's right. > > > >> The data in step (3) would be used by the ACM, though > getting it there > >> might require a gross violation of modularity in the SNMP engine. > > > > Why do you think so? > > Because unless _I'm_ terribly confused, the ACM doesn't do > authentication. > So if you can only talk to the RADIUS server if you do > authentication, or > use some form of cookie resulting from successfuly > authentication (I don't > know such a thing exists, but your previous writings have led > me to believe > there must be something like that), then _something_ has to > make its way > from the module that did authentication to the one that's > going to make > access control decisions. Since SNMP has gone to a fair bit > of trouble to > define the abstractions between modules rather than leaving > them up to the > implementors, that information has to fit the abstraction. > > > I wonder if maybe we have some sort of disconnect here. > Maybe Dave H or > one of the Juergen's can see what it is and tell us. > > -- Jeff > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 28 15:32:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvfle-00010n-RA; Wed, 28 Jun 2006 15:32:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvfle-00010Y-4I for isms@ietf.org; Wed, 28 Jun 2006 15:32:06 -0400 Received: from sccrmhc14.comcast.net ([63.240.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvfld-0001TM-P2 for isms@ietf.org; Wed, 28 Jun 2006 15:32:06 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (sccrmhc14) with SMTP id <200606281931570140088cc8e>; Wed, 28 Jun 2006 19:31:57 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'Nelson, David'" , Date: Wed, 28 Jun 2006 15:30:43 -0400 Message-ID: <069501c69ae9$58d688b0$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acaa0k11bCjeNMeVRvG14uvtm3Bp6wAEReyA In-Reply-To: <30C4DD888E6F3477C975C557@sirius.fac.cs.cmu.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: Subject: [Isms] An ACM/RADIUS integration X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, There are a number of potential solutions for using RADIUS for SNMP authorization. Some have been discussed to a degree. There seem to be two general things to consider: 1) what does the AAA server provide? 2) how does the server get contacted? -- what gets provided -- One approach would use AAA to actually populate the VACM tables with all the details needed to support a specific securityName. To use RADIUS, for example, would require the development of attributes to carry this information. (To me, this seems like using RADIUS to perform SNMP operations to configure the ACM model's MIB module, and it would require lots of info to be passed when the user initially makes a request. It also seems to imply that every user needs a customized VACM configuration, which I doubt is likely in real world deployments.) A second approach to using the AAA-provided attributes works on the assumption that the VACM filters are statically configured at system boot or management system startup or by a management application, and the AAA server will simply provide late binding between a securityname and a GroupName. This is similar to the RADIUS FilterID usage, where the AAA server only provides the name (or number) of a filter when the user requests access, and the details of the filter have already been configured on the system. -- how does the server get contacted? -- -- ACM subsystem add-on -- In the interim meeting one approach we discussed was an add-on to the ACM subsystem, in which the ACM subsystem extension is a AAA client whose job is to contact a AAA server and ask for the SNMP authorization information for a specified securityName. There is a security association between this client and the server that may be totally independent of any security association between the SSH transport-mapping's SSH client and any AAA server it uses. It would be best if we did not need to store credentials within the ACM subsystem to authenticate the securityName to the RADIUS server. There is already a SA between the client and server, and we want to simply use that SA to get the AAA server to tell us the SNMP filters to apply for that securityName. -- cached info -- Another approach works only when the same AAA server is advising a secure transport protocol (e.g. SSH) for the SNMP messages. When SSH user-auth is performed to establish a secure connection and an "snmp" SSH subsystem, the AAA server also passes along the information about the SNMP-ACM policies to apply to the SSH-specified user-name for the session. The AAA attributes get cached and passed to the ACM subsystem (or model) for subsequent use. We do not have an ASI parameter to pass this info, so either we need to modify the ASIs as is done with TMSM, or we pass the stuff in an implementation-dependent manner in the background. For example, if VACM is the ACM model, then the VACM tables get populated for a specific securityName when that securityName is determined in the SSH transport mapping. I hope this helps to identify the aspects of the problem better. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Wednesday, June 28, 2006 12:46 PM > To: Nelson, David; isms@ietf.org > Cc: Jeffrey Hutzelman > Subject: RE: [Isms] FW: RADIUS integration > > > > On Wednesday, June 28, 2006 11:18:30 AM -0400 "Nelson, David" > wrote: > > > Jeffrey Hutzelman writes... > > > >> This can't and won't happen in the ACM; it needs to happen > in the SSH > >> layer. > > > > Unless I'm mistaken, this is at variance with the recent > posting from > > Dave Harrington. It appears that we need to have some further > > discussion on this point. > > > >> Until a client has successfully authenticated to the SSH server, > >> it can't do anything that would be visible to the SNMP engine. > > > > Yes, that's true. Did it appear from my description that the > > SNMP-driven authorization phase would occur before the SSH-driven > > authentication phase? > > Yes, because you made specific reference to the SNMP Access > Control Module, > which is responsible for authorization, but not authentication. > > > > >> So, what we're really talking about in this scenario is > >> > >> (1) RADIUS as an authentication backend for SSH > >> (2) what you called "base-level" authorization to use SNMP > >> (3) optionally, additional data for fine-grained access control > > > > Yes, I think that's right. > > > >> The data in step (3) would be used by the ACM, though > getting it there > >> might require a gross violation of modularity in the SNMP engine. > > > > Why do you think so? > > Because unless _I'm_ terribly confused, the ACM doesn't do > authentication. > So if you can only talk to the RADIUS server if you do > authentication, or > use some form of cookie resulting from successfuly > authentication (I don't > know such a thing exists, but your previous writings have led > me to believe > there must be something like that), then _something_ has to > make its way > from the module that did authentication to the one that's > going to make > access control decisions. Since SNMP has gone to a fair bit > of trouble to > define the abstractions between modules rather than leaving > them up to the > implementors, that information has to fit the abstraction. > > > I wonder if maybe we have some sort of disconnect here. > Maybe Dave H or > one of the Juergen's can see what it is and tell us. > > -- Jeff > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 28 15:35:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvfpI-0006gN-GA; Wed, 28 Jun 2006 15:35:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvfpH-0006g5-AR for isms@ietf.org; Wed, 28 Jun 2006 15:35:51 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvfpC-0001wD-04 for isms@ietf.org; Wed, 28 Jun 2006 15:35:51 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 15:35:44 -0400 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 Date: Wed, 28 Jun 2006 15:35:43 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021930E@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SNMP "access control" terminology Thread-Index: Acaa0k11bCjeNMeVRvG14uvtm3Bp6wAAhmPgAAPtx5A= From: "Nelson, David" To: X-OriginalArrivalTime: 28 Jun 2006 19:35:44.0295 (UTC) FILETIME=[0C1DEB70:01C69AEA] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Subject: [Isms] RE: SNMP "access control" terminology X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org David Harrington writes... > I'll present my understanding of the RFCs and the intentions > of the authors to clarify this. This message is about the term > "access control" in SNMP. Thanks for explaining. =20 > The access control subsystem, the ACM, permits multiple models > of access control. An access control model advises applications > about who is allowed to do what operations to which objects in > which subsets of data. So here's some dumb questions: Is "access control" optional in SNMP? For example, is there a default that all authenticated principals get full access to all objects and operations? > SNMP traditionally has not worked with a session approach,=20 > so there is no concept of authorizing an snmp session in RFC3411. > It has been argued that authentication via USM implies authorization > to use SNMP at that engine. I believe that is incorrect. SNMPv3=20 > has no concept that a user is "authorized" by USM to perform SNMP > operations. If I understand this, any principal that can authenticate itself has the use of the SNMP engine, up to the point where an application might choose to deny access, based on consulting with the ACM. I think my point was that, with USM, no "unauthorized" principals=20 are likely to be configured in the usmUserTable, so users who "aren't on the list" don't get as far as making a request to an application. If we effectively export the "list", the analog of the usmUserTable, to a multi-purpose, enterprise-wide AAA system, there are likely to be lots of "unauthorized" users "on the list". Your point is that it is the function of the ACM to weed them out from the authorized users. Point taken. This presumes that the ACM obtains some authorization information from the AAA service, either directly, or via the SSH server. We need to describe how that happens. > For example, in an engine that only supports USM and VACM, "dbh" > could have an entry in the usmUserTable, and I might be able to > authenticate myself to an engine, but if VACM has no assignment > for the securityName "dbh" to an authorized group, then I am not > authorized to perform any SNMP operations on any objects in any > contexts at that entity. It is the VACM access control subsystem > that makes this determination, not the USM security model. So this part is clear. > So, when we talk about access control in SNMP, we really should > restrict that terminology to refer to the functionality provided by > the ACM subsystem. OK. Let's go with that. > RADIUS has the ability to advise a server which services should > be permitted when a client connects to a server. I think referring > to this as "access control" within an SNMP engine will cause=20 > nothing but problems. There may be a terminology issue, with how SNMP defines "access control", but there is a valid issue with the need for a RADIUS/AAA server to be able to provision services on the NAS. > The decision to permit access to an SSH subsytem called > "snmp" is based on a transaction between a RADIUS advisor,=20 > and an SSH enforcer (or "snmp" service provider). That would be a very nice way to implement the system. However, the problem with this approach is that it places normative requirements on SSH, at least SSH as used for SNMP. I don't think our charter allows us to proscribe such requirements. This would be under the title of "SSH-RADIUS Integration". I think this is a very good thing, and have in fact described RADIUS attributes that could be used to provision SSH in such a fashion. Are we in agreement that what I have called "base-level" service provisioning (the NAS providing SNMP service) should be enforced (implemented) in the SSH server? If so, does ISMS have leave to describe that behavior in a Standards Track RFC? > SNMP does not enter into this decision at all. SNMP will never > even see a message that comes to an SSH server, if the SSH server=20 > does not permit the "snmp" service. True, but this creates requirements for changes to existing SSH server implementations, I believe. Is this OK? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 28 15:49:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvg2T-0002mX-0H; Wed, 28 Jun 2006 15:49:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvg2R-0002mS-Rx for isms@ietf.org; Wed, 28 Jun 2006 15:49:27 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvg2M-0004TW-Iz for isms@ietf.org; Wed, 28 Jun 2006 15:49:27 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 15:49:21 -0400 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 Date: Wed, 28 Jun 2006 15:49:21 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021930F@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: An ACM/RADIUS integration Thread-Index: Acaa0k11bCjeNMeVRvG14uvtm3Bp6wAEReyAAAHSGbA= From: "Nelson, David" To: X-OriginalArrivalTime: 28 Jun 2006 19:49:21.0547 (UTC) FILETIME=[F33CADB0:01C69AEB] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [Isms] RE: An ACM/RADIUS integration X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org David Harrington writes... =20 > There are a number of potential solutions for using RADIUS for SNMP > authorization. Some have been discussed to a degree. There seem to be > two general things to consider: > 1) what does the AAA server provide? > 2) how does the server get contacted? Modulo my previous comments about how SSH interacts with RADIUS/AAA to provision SNMPv3 service, this description of "how it might work" coincides with my own thinking. Specific comments in-line. Sections deleted for brevity. > (To me, this seems like using RADIUS to perform SNMP operations to > configure the ACM model's MIB module, and it would require lots of > info to be passed when the user initially makes a request. It also > seems to imply that every user needs a customized VACM configuration, > which I doubt is likely in real world deployments.) I agree. > In the interim meeting one approach we discussed was an add-on to the > ACM subsystem, in which the ACM subsystem extension is a AAA client > whose job is to contact a AAA server and ask for the SNMP > authorization information for a specified securityName. There is a > security association between this client and the server that may be > totally independent of any security association between the SSH > transport-mapping's SSH client and any AAA server it uses. This represents the preferred "Authorize Only" mode of operation. > Another approach works only when the same AAA server is advising a > secure transport protocol (e.g. SSH) for the SNMP messages. When SSH > user-auth is performed to establish a secure connection and an "snmp" > SSH subsystem, the AAA server also passes along the information about > the SNMP-ACM policies to apply to the SSH-specified user-name for the > session. The AAA attributes get cached and passed to the ACM subsystem > (or model) for subsequent use. This represents the non-preferred "Authenticate and Authorize" mode of operation, i.e. the way RADIUS normally works. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 28 16:01:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvgE4-0002Ek-2V; Wed, 28 Jun 2006 16:01:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvgE2-0002Di-71 for isms@ietf.org; Wed, 28 Jun 2006 16:01:26 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvgDw-0005bv-VR for isms@ietf.org; Wed, 28 Jun 2006 16:01:26 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 16:01:19 -0400 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 Date: Wed, 28 Jun 2006 16:01:19 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219310@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should ACM close a subsystem? Thread-Index: Acaa0k11bCjeNMeVRvG14uvtm3Bp6wADoi/QAAMMOrA= From: "Nelson, David" To: X-OriginalArrivalTime: 28 Jun 2006 20:01:19.0567 (UTC) FILETIME=[9F35D5F0:01C69AED] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Isms] RE: Should ACM close a subsystem? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org David Harrington writes...=20 > It was suggested that an ACM model querying a RADIUS service might be > advised that a principal is not permitted to perform SNMP to the > device, and that the ACM model should request that the SSH subsystem > be closed. >=20 > I strongly disagree with this. >=20 > We want a separation between authentication and authorization. And we > want ACM models to be independent of the transport used. >=20 > If an implementer wants to optimize their implementation to do this, > fine, but it should not be part of the standard. So it doesn't concern you that unauthorized users are able to open SSH sessions and receive SNMP service? It is (hopefully) true that these unauthorized users won't be able to actually access any objects, because ACM is blocking them. This doesn't strike me as a good "defense in depth" design approach, however. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 28 16:58:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvh7P-0002GN-UB; Wed, 28 Jun 2006 16:58:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvh7O-0002Do-7W for isms@ietf.org; Wed, 28 Jun 2006 16:58:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvgFl-0005iQ-NV for isms@ietf.org; Wed, 28 Jun 2006 16:03:13 -0400 Received: from [63.240.77.83] (helo=sccrmhc13.comcast.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fvg6N-0004fm-Cm for isms@ietf.org; Wed, 28 Jun 2006 15:53:35 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (sccrmhc13) with SMTP id <2006062819523801300b4qkbe>; Wed, 28 Jun 2006 19:52:38 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'Nelson, David'" , Date: Wed, 28 Jun 2006 15:51:24 -0400 Message-ID: <069601c69aec$3cfa8c10$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acaa0k11bCjeNMeVRvG14uvtm3Bp6wADoi/Q In-Reply-To: <30C4DD888E6F3477C975C557@sirius.fac.cs.cmu.edu> X-Spam-Score: -2.6 (--) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Subject: [Isms] Should ACM close a subsystem? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org Hi, It was suggested that an ACM model querying a RADIUS service might be advised that a principal is not permitted to perform SNMP to the device, and that the ACM model should request that the SSH subsystem be closed. I strongly disagree with this. We want a separation between authentication and authorization. And we want ACM models to be independent of the transport used. If an implementer wants to optimize their implementation to do this, fine, but it should not be part of the standard. An important part of the goal of the separation of authentication and authorization is the desire to mix-and-match to meet operational requirements. Some want to authenticate via kerberos but use RADIUS for centralized authorization. In one approach, in which an ACM extension AAA-client talks directly with a RADIUS server, there may not even be an SSH "snmp" subsystem to close. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Wednesday, June 28, 2006 12:46 PM > To: Nelson, David; isms@ietf.org > Cc: Jeffrey Hutzelman > Subject: RE: [Isms] FW: RADIUS integration > > > > On Wednesday, June 28, 2006 11:18:30 AM -0400 "Nelson, David" > wrote: > > > Jeffrey Hutzelman writes... > > > >> This can't and won't happen in the ACM; it needs to happen > in the SSH > >> layer. > > > > Unless I'm mistaken, this is at variance with the recent > posting from > > Dave Harrington. It appears that we need to have some further > > discussion on this point. > > > >> Until a client has successfully authenticated to the SSH server, > >> it can't do anything that would be visible to the SNMP engine. > > > > Yes, that's true. Did it appear from my description that the > > SNMP-driven authorization phase would occur before the SSH-driven > > authentication phase? > > Yes, because you made specific reference to the SNMP Access > Control Module, > which is responsible for authorization, but not authentication. > > > > >> So, what we're really talking about in this scenario is > >> > >> (1) RADIUS as an authentication backend for SSH > >> (2) what you called "base-level" authorization to use SNMP > >> (3) optionally, additional data for fine-grained access control > > > > Yes, I think that's right. > > > >> The data in step (3) would be used by the ACM, though > getting it there > >> might require a gross violation of modularity in the SNMP engine. > > > > Why do you think so? > > Because unless _I'm_ terribly confused, the ACM doesn't do > authentication. > So if you can only talk to the RADIUS server if you do > authentication, or > use some form of cookie resulting from successfuly > authentication (I don't > know such a thing exists, but your previous writings have led > me to believe > there must be something like that), then _something_ has to > make its way > from the module that did authentication to the one that's > going to make > access control decisions. Since SNMP has gone to a fair bit > of trouble to > define the abstractions between modules rather than leaving > them up to the > implementors, that information has to fit the abstraction. > > > I wonder if maybe we have some sort of disconnect here. > Maybe Dave H or > one of the Juergen's can see what it is and tell us. > > -- Jeff > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 28 17:30:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvhcK-0005gj-Ld; Wed, 28 Jun 2006 17:30:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvhcJ-0005fY-2L for isms@ietf.org; Wed, 28 Jun 2006 17:30:35 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvhcE-0008Du-G4 for isms@ietf.org; Wed, 28 Jun 2006 17:30:35 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 17:30:29 -0400 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] RE: SNMP "access control" terminology Date: Wed, 28 Jun 2006 17:30:30 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219313@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: SNMP "access control" terminology Thread-Index: Acaa0k11bCjeNMeVRvG14uvtm3Bp6wAAhmPgAAPtx5AAAfWRwAACjr6A From: "Nelson, David" To: X-OriginalArrivalTime: 28 Jun 2006 21:30:29.0946 (UTC) FILETIME=[1448E1A0:01C69AFA] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org David Harrington writes... > 1) access control is optional, to a degree. It is an advisory > functionality used by an application. > 2) The default configuration of VACM is determined by an=20 > administrator (and the ability of an implementation to support=20 > their decision. Hmmm. This means that a security analysis of the ISMS work is dependent upon administrative configuration, for which the standard has no default values. It that right? That may not be a big problem, or even unusual, but it will likely play into the security considerations section. =20 > It would be incorrect to assume that the policies MUST come from > a AAA server, or from the same AAA server that was part of the > authentication process. True. I was attempting to describe what MUST happen if such policies are in fact provisioned by a given AAA service. > > This would be under the title of > > "SSH-RADIUS Integration". I think this is a very good thing, and > > have in fact described RADIUS attributes that could be used to > > provision SSH in such a fashion. >=20 > What are the normative requirements you mention? > Let me be clear that SSH does NOT need to use RADIUS at all. Yes, of course. The requirement I'm thinking of is along the lines of: It is optional to use RADIUS (or any other AAA service) to provision SNMP service via SSH, using SSHSM. If an implementation (and its configuration) chooses to use AAA provisioning, this document describes how it is to be implemented, including normative requirements as to authentication, authorization and bindings between the two. Or something vaguely along those lines. The "If you choose to use it, this is how you MUST use it", sort of thing. We can debate whether the keywords ought to be MUST, SHOULD or RECOMMENDED, depending on what level of security assurances we might like to make. > 1) SSH provides an "snmp" subsystem. I'm not sure NAS is=20 > appropriate here. "NAS" is RADIUS-speak for the system which contains the RADIUS client, and upon which a RADIUS server provisions service, for an attached user. > I'm not sure whether your "base-level" service provisioning goes > beyond that. No, it doesn't. > 3) If SSH chooses to use a RADIUS server to advise it whether to > provide the "snmp" subsystem requested by the SSH user, then SNMP > should know nothing about the fact that SSH chose to consult RADIUS. If SSH is the enforcer of the SNMP service, and there is no desire to pass along "access control" information from an initial authentication and authorization response, then yes. If we hold open the possibility of an operational mode in which SSH passes "access control" information (like a policy name) for the ACM to use, then no. > I'm not sure what other changes are required to SSH. Do SSH server implementations today actually provision SNMP service based on authorization attributes from an AAA service? I think the answer is no. That is the type of change that I had envisioned. > There are other changes that COULD be made to an SSH server. For > example, such an SSH server might support the "managament" attributes > you have proposed. But I'm not sure that is a requirement. If you follow the RADIUS or Diameter architectures, and you have configured AAA "control" of the services offered on the NAS, then IMHO, this is a requirement. AAA is generally more about mandatory provisioning, and less about advisory provisioning. Of course, the NAS is the point of enforcement, so in terms of implementation behavior it's always advisory. However, in order for such an implementation to be compliant with the normative requirements of RADIUS and Diameter RFCs, the enforcement of service provisioning is mandatory. I suspect this might be at variance with the SNMP architecture. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 28 17:35:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvhgw-00014i-N0; Wed, 28 Jun 2006 17:35:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvhgw-00014S-Du for isms@ietf.org; Wed, 28 Jun 2006 17:35:22 -0400 Received: from sccrmhc13.comcast.net ([63.240.77.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvhgv-0000jE-4Q for isms@ietf.org; Wed, 28 Jun 2006 17:35:22 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (sccrmhc13) with SMTP id <2006062821352001300b2kvse>; Wed, 28 Jun 2006 21:35:20 +0000 From: "David Harrington" To: "'Nelson, David'" , Subject: RE: [Isms] RE: Should ACM close a subsystem? Date: Wed, 28 Jun 2006 17:34:06 -0400 Message-ID: <079c01c69afa$95aafb70$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acaa0k11bCjeNMeVRvG14uvtm3Bp6wADoi/QAAMMOrAAAgxLgA== In-Reply-To: <3CFB564E055A594B82C4FE89D2156560219310@MABOSEVS2.ets.enterasys.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org > So it doesn't concern you that unauthorized users are able to open SSH > sessions and receive SNMP service? It is (hopefully) true that these > unauthorized users won't be able to actually access any > objects, because > ACM is blocking them. This doesn't strike me as a good "defense in > depth" design approach, however. Only an authorized user will be permitted to open the SSH session. That is, they will be authorized to open an SSH session, not necessarily to perform SNMP operations. It might be possible for SSH to restrict that further - only those authorized to open an SSH "snmp" subsystem will be allowed to open an SSH "snmp" subsystem. It is fine with me that a user authorized to open an "snmp" subsytem is permitted to do so. It is fine with me that an admin may configure the ACM model to deny the rights to actually do anything using SNMP, for a user authorized to open an SSH "snmp" subsystem. Let's consider a company with multiple operators authorized to get SNMP access to devices. Now let's consider that the company might have multiple locations, say Rochester and Andover, and that some operators are permitted to modify the SNMP configurations in Rochester, but only to read those in Andover, i.e. they are authorized to open an SSH "snmp" subsystem in either location. The company can distribute different static VACM configurations to the devices in Rochester and Andover, with the securityName of the particular admin assigned to groupname "super-user" or "read-only-user", depending on where the device is located. Or the VACM config could deny them the right to do anything at all with SNMP to that device, not even read SNMP. I don't really care if they can open the "snmp" subsystem, as long as they can only do the SNMP operations on that device that VACM allows. Note that I am talking about whether a user should be allowed to open a session, even if the VACM configuration prevents them from doing anything. I am not talking about whether distributing different static VACM configs to different locations is the best approach; I think there are better ways, but I think they are independent of whether the user can open an "snmp" subsystem and then not be permitted to do anything. Defense in depth is nice, but what happens if the user has access to the system both via SSH and USM and SNMPv1 communities? Why do we want to depend on SSH to determine whether the user can access the data? I want to depend on the ACM whose very purpose is to make that specific determination. dbh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 28 17:43:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvhoZ-00080v-BI; Wed, 28 Jun 2006 17:43:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvhoX-00080q-NT for isms@ietf.org; Wed, 28 Jun 2006 17:43:13 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvhoS-0002KV-Eu for isms@ietf.org; Wed, 28 Jun 2006 17:43:13 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe1.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 17:43:06 -0400 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] RE: Should ACM close a subsystem? Date: Wed, 28 Jun 2006 17:43:07 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219314@MABOSEVS2.ets.enterasys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] RE: Should ACM close a subsystem? Thread-Index: Acaa0k11bCjeNMeVRvG14uvtm3Bp6wADoi/QAAMMOrAAAgxLgAABm2DQ From: "Nelson, David" To: X-OriginalArrivalTime: 28 Jun 2006 21:43:07.0305 (UTC) FILETIME=[D7B4B190:01C69AFB] X-imss-version: 2.040 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org David Harrington writes... > Defense in depth is nice, but what happens if the user has=20 > access to the system both via SSH and USM and SNMPv1=20 > communities? Good point. You've got me, there. :-) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 28 17:44:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvhq7-0000zj-Qg; Wed, 28 Jun 2006 17:44:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvhq6-0000zK-Vg for isms@ietf.org; Wed, 28 Jun 2006 17:44:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvhEz-0006yB-W7 for isms@ietf.org; Wed, 28 Jun 2006 17:06:30 -0400 Received: from sccrmhc14.comcast.net ([204.127.200.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fvh2y-00067Q-6q for isms@ietf.org; Wed, 28 Jun 2006 16:54:07 -0400 Received: from harrington73653 (c-24-128-147-200.hsd1.nh.comcast.net[24.128.147.200]) by comcast.net (sccrmhc14) with SMTP id <20060628205401014008cjale>; Wed, 28 Jun 2006 20:54:01 +0000 From: "David Harrington" To: "'Nelson, David'" , Subject: RE: [Isms] RE: SNMP "access control" terminology Date: Wed, 28 Jun 2006 16:52:47 -0400 Message-ID: <06fa01c69af4$cfe44860$0400a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: Acaa0k11bCjeNMeVRvG14uvtm3Bp6wAAhmPgAAPtx5AAAfWRwA== In-Reply-To: <3CFB564E055A594B82C4FE89D215656021930E@MABOSEVS2.ets.enterasys.com> X-Spam-Score: -2.6 (--) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > > > So here's some dumb questions: Is "access control" optional in SNMP? > For example, is there a default that all authenticated principals get > full access to all objects and operations? 1) access control is optional, to a degree. It is an advisory functionality used by an application. Not all applications are required to ask the isAccessAllowed() question, and I think not all implementations are required to not permit an operation for which the answer is "no". This was done because there are some unusual circumstances that needed to be accommodated. I recall something about printers, but I do not recall just what the circumstances were. I think all the standard applications abort the operation if isAccessAllowed() returns "no". 2) The default configuration of VACM is determined by an administrator (and the ability of an implementation to support their decision). If an admin wants to set up their ACM to permit all users to do all things to all data, I suppose they could. If an admin wants to accept whatever the implementer configured, I suppose they could. I would need to walk through the Installation portion of RFC3415 to know whether the installation configuration suggested supports a "permit all" approach. > > > SNMP traditionally has not worked with a session approach, > > so there is no concept of authorizing an snmp session in RFC3411. > > It has been argued that authentication via USM implies authorization > > to use SNMP at that engine. I believe that is incorrect. SNMPv3 > > has no concept that a user is "authorized" by USM to perform SNMP > > operations. > > If I understand this, any principal that can authenticate > itself has the > use of the SNMP engine, up to the point where an application might > choose to deny access, based on consulting with the ACM. I believe that is correct. Not necessarily desirable, but correct. > > I think my point was that, with USM, no "unauthorized" principals > are likely to be configured in the usmUserTable, so users who > "aren't on > the list" don't get as far as making a request to an > application. Failure to authenticate when msgFlags says "auth" would cause processing to stop. I would assume most administartors would not include "unauthorized" principals in the usmUsertable. But I believe all an admin needs to do to stop an existing "authorized" principal from being authorized subsequently would be to remove the securityname-groupame mapping in VACM. The usm entries and the other vacm entries could exist, but without a securtyname-groupname mapping they would get nothing. I didn't look this up to double-check it, but I'm fairly sure this is the case. > If we > effectively export the "list", the analog of the usmUserTable, to a > multi-purpose, enterprise-wide AAA system, there are likely to be lots > of "unauthorized" users "on the list". Your point is that it is the > function of the ACM to weed them out from the authorized users. Point > taken. This presumes that the ACM obtains some authorization > information from the AAA service, either directly, or via the SSH > server. We need to describe how that happens. It presumes that the ACM has or obtains information about the ACM policies to apply. It would be incorrect to assume that the policies MUST come from a AAA server, or from the same AAA server that was part of the authentication process. It would be acceptable that the policies MAY come from the same server, or another AAA, or from another source altogether. Any "binding" between the authentication and authorization in SNMP is done via the securityName/securityModel parameters. > > There may be a terminology issue, with how SNMP defines "access > control", but there is a valid issue with the need for a RADIUS/AAA > server to be able to provision services on the NAS. I have no qualms with the fact that an SSH server may ask a RADIUS server for advice about whether to permit the establishment of an "snmp" subsystem associated with the SSH user-name. > > > The decision to permit access to an SSH subsytem called > > "snmp" is based on a transaction between a RADIUS advisor, > > and an SSH enforcer (or "snmp" service provider). > > That would be a very nice way to implement the system. However, the > problem with this approach is that it places normative requirements on > SSH, at least SSH as used for SNMP. I don't think our > charter allows us > to proscribe such requirements. This would be under the title of > "SSH-RADIUS Integration". I think this is a very good thing, and have > in fact described RADIUS attributes that could be used to > provision SSH > in such a fashion. What are the normative requirements you mention? Let me be clear that SSH does NOT need to use RADIUS at all. The choice to do so is a deployment decision made by the operator. SNMP in no way requires it, and SNMP should not even know about the RADIUS connection if SSH does use RADIUS to perform authentication. > > Are we in agreement that what I have called "base-level" service > provisioning (the NAS providing SNMP service) should be enforced > (implemented) in the SSH server? If so, does ISMS have leave to > describe that behavior in a Standards Track RFC? 1) SSH provides an "snmp" subsystem. I'm not sure NAS is appropriate here. I'm not sure whether your "base-level" service provisioning goes beyond that. 2) I'll let the chairs and AD decide what ISMS has leave to do in a Standard Track RFC. 3) If SSH chooses to use a RADIUS server to advise it whether to provide the "snmp" subsystem requested by the SSH user, then SNMP should know nothing about the fact that SSH chose to consult RADIUS. > > > SNMP does not enter into this decision at all. SNMP will never > > even see a message that comes to an SSH server, if the SSH server > > does not permit the "snmp" service. > > True, but this creates requirements for changes to existing SSH server > implementations, I believe. Is this OK? What changes are you referring to? It requires that the SSH server used must be able to open an "snmp" subsystem. I'm not sure what other changes are required to SSH. There are other changes that COULD be made to an SSH server. For example, such an SSH server might support the "managament" attributes you have proposed. But I'm not sure that is a requirement. dbh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jun 30 18:14:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwRFg-00063b-8v; Fri, 30 Jun 2006 18:14:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwRFf-00063W-F2 for isms@ietf.org; Fri, 30 Jun 2006 18:14:15 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwRFe-0003ou-1R for isms@ietf.org; Fri, 30 Jun 2006 18:14:15 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 316EA56095; Sat, 1 Jul 2006 00:14:13 +0200 (CEST) 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 11879-02; Sat, 1 Jul 2006 00:14:10 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id AB86B4D739; Sat, 1 Jul 2006 00:14:10 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 375C977EBCB; Sat, 1 Jul 2006 00:14:07 +0200 (CEST) Date: Sat, 1 Jul 2006 00:14:07 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [Isms] SNMP "access control" terminology Message-ID: <20060630221407.GA1652@boskop.local> Mail-Followup-To: David Harrington , 'Jeffrey Hutzelman' , "'Nelson, David'" , isms@ietf.org References: <30C4DD888E6F3477C975C557@sirius.fac.cs.cmu.edu> <068601c69ae1$72d0e650$0400a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <068601c69ae1$72d0e650$0400a8c0@china.huawei.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: isms@ietf.org, 'Jeffrey Hutzelman' 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Wed, Jun 28, 2006 at 02:34:10PM -0400, David Harrington wrote: > A little history: > > The processIncomingMsg() ASI lacks the parameters to pass the > transportAddress information from an incoming message into the > security model. Wonder why? It was not an oversight. > > During the discussions of SNMPv2 and SNMPv3 designs, there was a > persistent request by operators for support of an approach frequently > used as an authorization mechanism. This was the practice of only > allowing certain IP addresses (e.g. from the NOC) to perform SNMP at a > device. > > This was deliberately excluded from the design of SNMPv3. The > authentication and the authorization aspects of that approach are much > weaker than the authentication provided by USM and the authorization > provided by VACM. SNMPv3 design exlicitly separates authentication of > the principal, and authorization to perform SNMP operations. There is > no authorization implied by the authentication of a principal. So how do you think snmpCommunityTransportTag as defined in RFC 3587 fits into the picture? I believe this object does authorization by matching IP addresses. And the way it is described, this happens in the message processing model (processIncomingMsg ASI, see RFC 3587 section 5.2.1). Perhaps this RFC is wrong according to the architecture (or is the architecture wrong? ;-) You like to see authorization in the ACM. I think authorization does not really exist as a concept - except perhaps in RFC 3587. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Jun 30 18:15:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwRGf-00066N-Q4; Fri, 30 Jun 2006 18:15:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwRGe-00066H-II for isms@ietf.org; Fri, 30 Jun 2006 18:15:16 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwRGd-0003qj-8z for isms@ietf.org; Fri, 30 Jun 2006 18:15:16 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id CE037560C6; Sat, 1 Jul 2006 00:15:14 +0200 (CEST) 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 12033-03; Sat, 1 Jul 2006 00:15:12 +0200 (CEST) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id EC83655C66; Sat, 1 Jul 2006 00:15:11 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id B4ADE77EBEC; Sat, 1 Jul 2006 00:15:09 +0200 (CEST) Date: Sat, 1 Jul 2006 00:15:09 +0200 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] New drafts Message-ID: <20060630221509.GB1652@boskop.local> Mail-Followup-To: David B Harrington , isms@ietf.org References: <002e01c6971d$bf7c06a0$0400a8c0@china.huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002e01c6971d$bf7c06a0$0400a8c0@china.huawei.com> User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: isms-bounces@lists.ietf.org On Fri, Jun 23, 2006 at 07:35:44PM -0400, David B Harrington wrote: > I just submitted updates to TMSM and SSHSM documents to include the > comments made earlier. The update to SSHSM is minor, but helps to make > TMSM and SSHSM more in sync. Thanks Dave for updating the WG drafts. They meanwhile appeared and we have updated the meeting agenda page to point to the updated IDs. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms