From isms-bounces@lists.ietf.org Thu Nov 08 16:48:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFEu-0006rH-E7; Thu, 08 Nov 2007 16:48:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFEs-0006o7-76 for isms@ietf.org; Thu, 08 Nov 2007 16:48:38 -0500 Received: from qmta10.emeryville.ca.mail.comcast.net ([76.96.30.17]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqFEr-0006Np-7z for isms@ietf.org; Thu, 08 Nov 2007 16:48:38 -0500 Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA10.emeryville.ca.mail.comcast.net with smtp id AHoc1Y0010cQ2SL010H200; Thu, 08 Nov 2007 21:48:38 +0000 Received: from Harrington73653 ([24.128.104.207]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id AMoV1Y0084UVsHU0000000; Thu, 08 Nov 2007 21:48:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=j3Z76cjpAAAA:8 a=9b93FF_exsyWgeYac68A:9 a=DPtS23sK-XBlKV8zKhsA:7 a=9Tehx2INXCsACZaciyZUIswLS0cA:4 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: , "'Wijnen, Bert \(Bert\)'" References: <20070911074306.GD16313@elstar.local> Subject: RE: [Isms] my review of: draft-ietf-isms-secshell-08.txt Date: Thu, 8 Nov 2007 16:48:08 -0500 Message-ID: <00d201c82251$0e2d8a20$6502a8c0@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: <20070911074306.GD16313@elstar.local> Thread-Index: Acf0R2i2Id5/brmOTDSPPt0XDpxRsAuAWoig X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 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 > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, September 11, 2007 3:43 AM > To: Wijnen, Bert (Bert) > Cc: David Harrington; jsalowey@cisco.com; isms@ietf.org > Subject: Re: [Isms] my review of: draft-ietf-isms-secshell-08.txt > > On Thu, Aug 09, 2007 at 12:17:13PM +0200, Wijnen, Bert (Bert) wrote: > > > > Some of these are NITs, I know that. > > > > - I think the abstract should also mention that there is a > MIB module > > defined in this document. > > > > - I think the last para of sect 1.2 can/should be removed, > or at least > > the > > RFC-Editor should be instructed to do so. > > editorial done. > > > - Sect 1.4 > > > > The work will address ... > > > > The work will include ... > > > > Maybe better: This document addresses ... > > This document includes/defines ... > > editorial done. > > > - sect 5.1 and 5.1 > > I assume that SSH_MSG_USERAUTH_REQUEST and SSH_MSG_CHANNEL_DATA > > are specified somewhere in the SSH RFC(s)? Maybe a citation to > > such RFC(s) is useful at these points. > > there were suggestions in the discussion to actually be less precise > concerning SNMP messages and this seems to solve this issue removed references to CHANNEL_DATA. I tried to make it clear that how one gets username from the SSH environment is implementation-dependent. > > > - top of page 15: > > 45 Extract any implementation-specific parameters from the LCD > > 6) Pass the wholeMessage to SSH for encapsulation in an > > SSH_MSG_CHANNEL_DATA message. > > > > what is "45"? Should that be "5)" > > But the whole first sentence seems to not belong here? > > editorial It should be 5). bullet 4 is conditional; bullet 5 is not. It belongs here so info is extracted from the LCD whether bullet 4 is triggered or not. Implementatins are free to optimize this. > > > - Should we root this MIB module under snmpModules? rooted under mib-2 > > see my arguments in my review of the MIB module in > > draft-ietf-isms-transport-security-model-05.txt > > > > If we do keep it under snmpModules, then > > sshtmMIB MODULE-IDENTITY > > possibly would be better > > snmpSshtmMIB MODULE-IDENTITY > > to be consistent with the other MIB modules under snmpModules. > > > > - Copyright in MIB module should be IETF Trust, not ISOC fixeed. > > > > - I see: > > sshtmGroups OBJECT IDENTIFIER ::= { sshtmConformance 1 } > > sshtmCompliances OBJECT IDENTIFIER ::= { sshtmConformance 2 } > > > > while RFC4181 suggests: > > > > xxxMIB > > | > > +-- xxxNotifications(0) > > +-- xxxObjects(1) > > +-- xxxConformance(2) > > | > > +-- xxxCompliances(1) > > +-- xxxGroups(2) > > > > i.e. first compliances, then groups. > > This needs to be dealt with according the resolution we achieve for > the TMS document. fixed. consistently. > > > - For SnmpSSHAddress ::= TEXTUAL-CONVENTION I read: > > > > "Represents either a hostname encoded in ASCII > > using the IDNA protocol, as specified in RFC3490, > followed by > > a colon ':' (ASCII character 0x3A) and a decimal port number > > in ASCII, or an IP address followed by a colon ':' > > (ASCII character 0x3A) and a decimal port number in ASCII. > > The name SHOULD be fully qualified whenever possible. > > > > I am not well versed/experienced in IDNA. But is IDNA a protocol? > > The title of 3490 reads > > Internationalizing Domain Names in Applications (IDNA) > > And are we indeed speaking of a hostname, or of a domain name, or > > of both? I can't quickly determine that. So I wonder if/hope that > > we can be clearer here. > > Seems to have been resolved in the discussion. text will hopefully respresent conensus. > > > I also assume (although this is not explicitly stated) that if we > > speak about an IP address, that it is a dotted decimal for > > IPv4 and and a colon separated IPv6 address in ASCII? Yes/no? > > > > I am concerned that for > > SnmpUDPAddress ::= TEXTUAL-CONVENTION > > DISPLAY-HINT "1d.1d.1d.1d/2d" > > we use a / sign to separate the port from the IPv4 address > > and here we use a colon (:). > > I must admit that (RFC3419) also uses : > > TransportAddressIPv4 ::= TEXTUAL-CONVENTION > > DISPLAY-HINT "1d.1d.1d.1d:2d" > > > > And what do we use for IPv6 addresses/ports? > > The SnmpUDPAddress notation goes back to the old days where a common > notation for transport endpoints did not exist yet. Nowadays, it is > common to read a.b.c.d/e as a prefix and a.b.c.d:e as an IPv4 > transport endpoint and [::]:e as an IPv6 transport endpoint. There is > an RFC specifying this IPv6 notion and we might just refer to it; I > think the latest document is RFC 3986 which obsoletes RFC 2732. Note > that also RFC 3419 uses the now more common notation and breaks with > the old SnmpUDPAddress notation. fixed. included a REFERENCE clause for RFC3986 > > > Further I read: > > > > When this textual convention is used as a syntax of an > > index object, there may be issues with the limit of 128 > > sub-identifiers specified in SMIv2, STD 58. In this case, > > the OBJECT-TYPE declaration MUST include a 'SIZE' clause > > to limit the number of potential instance sub-identifiers." > > > > Mmm.. we do not normally enforce (i.e. MUST language) that a SIZE > > clause must be used. We allo the DESCIRPTION clause to explain > > that implementers must be aware and cater for OID limitations. > > So do we really want that MUST language here? > > I think this text was copied from RFC 3419 which actually has MUST > language. RFC 4181 only RECOMMENDS to MIB documents are explicit by > either including SIZE constraints or specifying things in the row > DESCRIPTION clause. Since RFC 4181 is newer than RFC 3419, I suggest > that we adopt RFC 4181 language here. fixed. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Nov 08 17:07:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFXO-0003nH-QL; Thu, 08 Nov 2007 17:07:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFXN-0003nC-KL for isms@ietf.org; Thu, 08 Nov 2007 17:07:45 -0500 Received: from qmta03.emeryville.ca.mail.comcast.net ([76.96.30.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqFXK-0005F9-5D for isms@ietf.org; Thu, 08 Nov 2007 17:07:45 -0500 Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA03.emeryville.ca.mail.comcast.net with smtp id AMzx1Y0090mlR8U0101A00; Thu, 08 Nov 2007 22:07:43 +0000 Received: from Harrington73653 ([24.128.104.207]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id AN7e1Y00J4UVsHU0000000; Thu, 08 Nov 2007 22:07:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=mbt7lPP0l3XsxHXRqiIA:9 a=ig8saFd01vpYqk79VGUA:7 a=hlBZgU5Xu2c3697MZtsKuUdL5o0A:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=3I_whO4B8K8A:10 From: "David Harrington" To: References: <010801c80125$20960720$6502a8c0@china.huawei.com> <00a201c801f1$20c6ba60$0601a8c0@pc6> Subject: RE: [Isms] SnmpSSHAddress Date: Thu, 8 Nov 2007 17:07:17 -0500 Message-ID: <00d301c82253$ba9906c0$6502a8c0@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: <00a201c801f1$20c6ba60$0601a8c0@pc6> Thread-Index: AcgB+nEKz2qPCCskSGe+7lmABJNfgAgWTU9Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Juergen mentioned RFC3986, which does deal with ports. I used that RFC. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Friday, September 28, 2007 12:57 PM > To: David Harrington; isms@ietf.org > Subject: Re: [Isms] SnmpSSHAddress > > > ----- Original Message ----- > From: "David Harrington" > To: > Sent: Thursday, September 27, 2007 6:40 PM > Subject: [Isms] SnmpSSHAddress > > > > Hi, > > > > Bert and Jeff raised questions about the format for IPv4/IPv6 > > addresses and hostnames. Is the following acceptable? > > > > Is there an RFC that describes the textual representation of an IPv6 > > address? > > RFC4291 s2.2 > > The ABNF for this is somewhere unexpected (which I will stumble across > sometime). > > But note that this section does not cover the interface > number, which has > provoked discussion on URI because of the use of the percent > character, nor the > port number > > Tom Petch > > > > > Bert pointed out that MIB addresses have been inconsistent > - some use > > '/' to separate the port nunber and others use ':'. Jeff pointed out > > that using a colon makes it difficult to determine where an IPv6 > > address ends and the port starts. Maybe we should use the ':' > > separator for the hostname format, and the '/' separator for the IP > > address formats to eliminate the ambiguity. RFC4181 has no > guidance on > > this point; are there other documents that provide guidance on the > > separator character for hostnames and/or IP adddresses? > > > > SnmpSSHAddress ::= TEXTUAL-CONVENTION > > DISPLAY-HINT "1a" > > STATUS current > > DESCRIPTION > > "Represents either a hostname with a port number or an IP > > address with a port number. > > > > The hostname must be encoded in ASCII, as specified in > > RFC3490 (Internationalizing Domain Names in Applications) > > followed by a colon ':' (ASCII character 0x3A) and a > > decimal port number in ASCII. The name SHOULD be fully > > qualified whenever possible. > > > > An IPv4 address must be a dotted decimal format followed > > by a colon ':' (ASCII character 0x3A) and a decimal port > > number in ASCII. > > > > An IPv6 address must be a colon separated format, > > surrounded by brackets, followed by a colon ':' (ASCII > > character 0x3A) and a decimal port number in ASCII. > > > > Values of this textual convention may not be > directly useable > > as transport-layer addressing information, and may require > > runtime resolution. As such, applications that write them > > must be prepared for handling errors if such values are > > not supported, or cannot be resolved (if resolution occurs > > at the time of the management operation). > > > > The DESCRIPTION clause of TransportAddress objects that may > > have snmpSSHAddress values must fully describe how (and > > when) such names are to be resolved to IP > addresses and vice > > versa. > > > > This textual convention SHOULD NOT be used directly in > > object definitions since it restricts addresses to a > > specific format. However, if it is used, it MAY be used > > either on its own or in conjunction with > > TransportAddressType or TransportDomain as a pair. > > > > When this textual convention is used as a syntax of an > > index object, there may be issues with the limit of 128 > > sub-identifiers specified in SMIv2, STD 58. In this case, > > the OBJECT-TYPE declaration MUST include a 'SIZE' clause > > to limit the number of potential instance sub-identifiers." > > SYNTAX OCTET STRING (SIZE (1..255)) > > > > David Harrington > > dbharrington@comcast.net > > ietfdbh@comcast.net > > > > > > > > _______________________________________________ > > 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 Thu Nov 08 17:16:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFfc-0003na-GY; Thu, 08 Nov 2007 17:16:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFfC-0002fI-Ff for isms@ietf.org; Thu, 08 Nov 2007 17:15:50 -0500 Received: from qmta05.emeryville.ca.mail.comcast.net ([76.96.30.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqFfB-0007HE-G9 for isms@ietf.org; Thu, 08 Nov 2007 17:15:50 -0500 Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA05.emeryville.ca.mail.comcast.net with smtp id AMMi1Y0060b6N640105n00; Thu, 08 Nov 2007 22:15:50 +0000 Received: from Harrington73653 ([24.128.104.207]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id ANFl1Y00A4UVsHU0000000; Thu, 08 Nov 2007 22:15:51 +0000 X-Authority-Analysis: v=1.0 c=1 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=9fZCvQaKNaFnNS2svQgA:9 a=LwFA5QHNKLbNEvu4p3QdhRQwGCMA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , References: <20070918160505.GB22768@elstar.local> Subject: RE: [Isms] properly closing an ssh session Date: Thu, 8 Nov 2007 17:15:24 -0500 Message-ID: <00d401c82254$dd0097e0$6502a8c0@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: <20070918160505.GB22768@elstar.local> Thread-Index: Acf6EVwaX3yS2+FvTaG/eNY0VE9sxAoQzqWQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 see no record of a reply to this question, so the secshell document does not deal with this. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, September 18, 2007 12:05 PM > To: isms@ietf.org > Subject: [Isms] properly closing an ssh session > > Hi, > > I have a question for SSH experts (hope there are some on this list). > I am wondering what the proper way of closing the SSH session is in > our case. Note that we run a single SSH channel over the SSH transport > and there are several options now. > > a) Be brutal and simply close the underlying TCP connection. > > b) Be a bit less brutal and send an SSH_DISCONNECT with say a > reason code of SSH_DISCONNECT_BY_APPLICATION and be done. > > c) Be friendly and play the game of doing an SSH_CHANNEL_CLOSE > exchange followed by SSH_DISCONNECT. > > d) Be overly friendly by exchanging SSH_CHANNEL_EOF before > exchanging SSH_CHANNEL_CLOSE and doing an SSH_DISCONNECT. > > My reading of the RFCs indicates that d) is not really required and of > course a) will always work. There might be reasons to do b) although > it is not clear which benefit one would get (since my understanding is > that SSH_DISCONNECT does not impact who is closing the TCP connection > and who has to go into wait state). > > Any suggestions what should be done to play the SSH game nicely? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > 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 Nov 09 11:39:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWtG-0007qV-OP; Fri, 09 Nov 2007 11:39:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWtF-0007qP-FY for isms@ietf.org; Fri, 09 Nov 2007 11:39:29 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqWtF-00013K-66 for isms@ietf.org; Fri, 09 Nov 2007 11:39:29 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id B3EB9175B3; Fri, 9 Nov 2007 16:38:58 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IqWsk-0007PZ-2m; Fri, 09 Nov 2007 11:38:58 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: dharrington@huawei.com From: IETF I-D Submission Tool Message-Id: Date: Fri, 09 Nov 2007 11:38:58 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: isms@ietf.org Subject: [Isms] New Version Notification for draft-ietf-isms-secshell-09 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 A new version of I-D, draft-ietf-isms-secshell-09.txt has been successfuly submitted by David Harrington and posted to the IETF repository. Filename: draft-ietf-isms-secshell Revision: 09 Title: Secure Shell Transport Model for SNMP Creation_date: 2007-11-08 WG ID: isms Number_of_pages: 37 Abstract: This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell protocol (SSH). This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. The IETF Secretariat. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Nov 09 11:40:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWts-0008Ds-Pn; Fri, 09 Nov 2007 11:40:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWtq-0008BI-8r; Fri, 09 Nov 2007 11:40:06 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqWtm-0004I3-8C; Fri, 09 Nov 2007 11:40:06 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 366DF32899; Fri, 9 Nov 2007 16:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IqWtm-0005sk-4K; Fri, 09 Nov 2007 11:40:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 09 Nov 2007 11:40:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-secshell-09.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 Transport Model for SNMP Author(s) : D. Harrington, J. Salowey Filename : draft-ietf-isms-secshell-09.txt Pages : 37 Date : 2007-11-08 This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell protocol (SSH). This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-09.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-09.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-09.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: <2007-11-09113853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-secshell-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-secshell-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-09113853.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 Sun Nov 11 16:48:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrKf7-0003dH-DW; Sun, 11 Nov 2007 16:48:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrKf5-0003Sr-Ca for isms@ietf.org; Sun, 11 Nov 2007 16:48:11 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrKf0-0003Nv-Td for isms@ietf.org; Sun, 11 Nov 2007 16:48:11 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7F755AD6D; Sun, 11 Nov 2007 22:48:05 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 22192-10; Sun, 11 Nov 2007 22:48:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 129B771CE9; Sun, 11 Nov 2007 22:48:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5FAD93D53C1; Sun, 11 Nov 2007 22:48:01 +0100 (CET) Date: Sun, 11 Nov 2007 22:48:01 +0100 From: Juergen Schoenwaelder To: "David B. Nelson" Subject: Re: [Isms] Request for review of Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models Message-ID: <20071111214801.GA18374@elstar.local> Mail-Followup-To: "David B. Nelson" , isms@ietf.org References: <20070926201354.GA27245@elstar.local> <003a01c805e6$e3d84e80$5d1216ac@xpsuperdvd2> <005801c811d3$d0dd6100$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005801c811d3$d0dd6100$5d1216ac@xpsuperdvd2> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.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 Thu, Oct 18, 2007 at 06:11:21PM -0400, David B. Nelson wrote: > Following up on my previous post, I'd like to get active review of the ISMS > RADIUS Usage document > (http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-usage-00.txt), > even if we are not ready to formally call for WGLC. Here is my review of draft-ietf-isms-radius-usage-00.txt. In general, the document seems fine; my comments are mostly editorial. Note that I have some comments concerning the definitions in [radman] that I will post to the radext mailing list and the resolution might affect this document. While reading the ID, I had the feeling there is some repetition and redundancy in the document but then I am probably too much involved in this to judge readability from the point of a casual reader. a) p4: s/small a sub-set/a small sub-set/ b) p5: the following text perhaps can be simplified OLD Secure transport protocols used with SNMP Transport Models have defined authentication protocols that allows for authentication by various methods. For example, the Secure Shell (SSH) Authentication protocol [RFC4252] describes an authentication protocol and support multiple methods that can be used SSH servers to authenticate the SSH client, these methods include Public Key, Password and Host (e.g.hosts.equiv). NEW Some secure transport protocols that can be used with SNMP Transport Models have defined authentication protocols supporting several authentication methods. For example, the Secure Shell (SSH) Authentication protocol [RFC4252] supports multiple methods (Public Key, Password, Host-Based) to authenticate SSH clients. c) p6: some suggested rewording OLD There are three ways in which RADIUS may be used to inform the use of SNMP Transport Models. NEW There are three ways in which RADIUS may be used by SNMP Transport Models. d) p6: s/a authenticated/an authenticated/ e) p6: s/deployed models/deployed security models/ f) p6: s/the ACM uses/the ACS uses/ g) p6: s/Access Control Method/Access Control Model/ h) p7: s/they type/the type/ i) p8: s/be optionally be used,/be optionally used/ j) p9: you might add an informative reference to VACM in section 2.4 k) p11: s/Dave/David/ l) p11: reference [RFC4252] is incomplete /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Nov 12 15:28:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irfty-0001vw-FO; Mon, 12 Nov 2007 15:28:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irftx-0001rB-CT for isms@ietf.org; Mon, 12 Nov 2007 15:28:57 -0500 Received: from mail.elbrysnetworks.com ([64.140.243.164] helo=gumby.elbrysnetworks.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Irftr-0003UN-Lt for isms@ietf.org; Mon, 12 Nov 2007 15:28:57 -0500 Received: (qmail 30006 invoked from network); 12 Nov 2007 15:29:34 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 12 Nov 2007 15:29:34 -0500 From: "David B. Nelson" To: References: <20070926201354.GA27245@elstar.local> <003a01c805e6$e3d84e80$5d1216ac@xpsuperdvd2> <005801c811d3$d0dd6100$5d1216ac@xpsuperdvd2> <20071111214801.GA18374@elstar.local> Subject: RE: [Isms] Request for review of Remote Authentication Dial-InUser Service (RADIUS) Usage for Simple Network Management Protocol(SNMP) Transport Models Date: Mon, 12 Nov 2007 15:27:25 -0500 Organization: Elbrys Networks, Inc. Message-ID: <010801c8256a$702e4220$091716ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcgkrKdOICBRfPewR+SJKfD3U4QSDQAvJb1w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20071111214801.GA18374@elstar.local> X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Juergen Schoenwaelder writes... > Here is my review of draft-ietf-isms-radius-usage-00.txt. Thanks! > In general, the document seems fine; my comments are mostly > editorial. Note that I have some comments concerning the > definitions in [radman] that I will post to the radext mailing > list and the resolution might affect this document. Note that the RADEXT WGLC on [radman] formally closed on October 19. One review was received last week. We haven't issued a revised draft yet, so comments are still welcome. It would be appreciated if you could find time to send in those comments this week. > While reading the ID, I had the feeling there is some repetition > and redundancy in the document but then I am probably too much > involved in this to judge readability from the point of a casual > reader. Given the editorial history, I suspect that is correct. We added introductory material following the suggestion of Dave Harrington, and that probably contributed to the repetition problem. I'll take a fresh look at the structure, to see if it is easy to reduce redundant text. > b) p5: the following text perhaps can be simplified > > OLD > > Secure transport protocols used with SNMP Transport Models have > defined authentication protocols that allows for authentication by > various methods. For example, the Secure Shell (SSH) Authentication > protocol [RFC4252] describes an authentication protocol and support > multiple methods that can be used SSH servers to authenticate the SSH > client, these methods include Public Key, Password and Host > (e.g.hosts.equiv). > > NEW > > Some secure transport protocols that can be used with SNMP > Transport Models have defined authentication protocols > supporting several authentication methods. For example, the > Secure Shell (SSH) Authentication protocol [RFC4252] supports > multiple methods (Public Key, Password, Host-Based) to > authenticate SSH clients. Looks good to me. > c) p6: some suggested rewording > > OLD > > There are three ways in which RADIUS may be used to inform the use of > SNMP Transport Models. > > NEW > > There are three ways in which RADIUS may be used by SNMP > Transport Models. OK. > j) p9: you might add an informative reference to VACM in section 2.4 OK. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Nov 18 19:20:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItuN2-0000N7-CO; Sun, 18 Nov 2007 19:20:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItuMw-0000Hu-NN; Sun, 18 Nov 2007 19:20:06 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItuMs-0005cN-Ad; Sun, 18 Nov 2007 19:20:06 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 373CD2AB69; Mon, 19 Nov 2007 00:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItuMs-0006zK-4K; Sun, 18 Nov 2007 19:20:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 18 Nov 2007 19:20:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-tmsm-11.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 Subsystem for the Simple Network Management Protocol (SNMP) Author(s) : D. Harrington, J. Schoenwaelder Filename : draft-ietf-isms-tmsm-11.txt Pages : 34 Date : 2007-11-18 This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transport to include secure transport such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-11.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-11.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-11.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: <2007-11-18191808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-tmsm-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-tmsm-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18191808.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 Sun Nov 18 19:20:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItuN2-0000NE-Hn; Sun, 18 Nov 2007 19:20:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItuMw-0000IV-PS; Sun, 18 Nov 2007 19:20:06 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItuMs-0005cO-G1; Sun, 18 Nov 2007 19:20:06 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 51EC22AB6B; Mon, 19 Nov 2007 00:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItuMs-0006zM-4v; Sun, 18 Nov 2007 19:20:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 18 Nov 2007 19:20:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-transport-security-model-07.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 Security Model for SNMP Author(s) : D. Harrington Filename : draft-ietf-isms-transport-security-model-07.txt Pages : 27 Date : 2007-11-18 This memo describes a Transport Security Model for the Simple Network Management Protocol. This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for monitoring and managing the Transport Security Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-model-07.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-transport-security-model-07.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-transport-security-model-07.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: <2007-11-18191839.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-transport-security-model-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-transport-security-model-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18191839.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 Nov 19 02:00:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu0c6-0007XY-Ji; Mon, 19 Nov 2007 02:00:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu0c0-0007B8-HX; Mon, 19 Nov 2007 02:00:04 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu0by-0001lX-5l; Mon, 19 Nov 2007 02:00:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 15691328F4; Mon, 19 Nov 2007 07:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu0bx-0002mk-Ra; Mon, 19 Nov 2007 02:00:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 02:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-radius-usage-01.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 : Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models Author(s) : K. Narayan, D. Nelson Filename : draft-ietf-isms-radius-usage-01.txt Pages : 14 Date : 2007-11-19 This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service by Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell Transport Model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-usage-01.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-radius-usage-01.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-radius-usage-01.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: <2007-11-19015630.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-radius-usage-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-radius-usage-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19015630.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--