From isms-bounces@lists.ietf.org Tue Jun 19 20:01:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nd4-0007sa-4o; Tue, 19 Jun 2007 20:00:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nd3-0007sV-2v for isms@ietf.org; Tue, 19 Jun 2007 20:00:57 -0400 Received: from sccrmhc11.comcast.net ([63.240.77.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0nd1-00007w-Sg for isms@ietf.org; Tue, 19 Jun 2007 20:00:57 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <2007062000005501100ckdmte>; Wed, 20 Jun 2007 00:00:55 +0000 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'tom.petch'" References: <05a501c7779e$ae2ef6c0$0601a8c0@pc6> <00b701c77c61$51dda2a0$0601a8c0@pc6><20070412064949.GB7796@elstar.local> <013901c7873b$4025fc80$0601a8c0@pc6> <01f501c7874d$cd22a5e0$0600a8c0@china.huawei.com> <05bd01c788e7$ff4ce1c0$0601a8c0@pc6> <6328B76F92A0AE1C0068C68F@sirius.fac.cs.cmu.edu> <020301c79986$e155c330$0600a8c0@china.huawei.com> <450809FCECF0B4F4E1695A99@sirius.fac.cs.cmu.edu> <024d01c7998e$c01ab510$0600a8c0@china.huawei.com> <560465D5DCE4E968F0FC3AA7@sirius.fac.cs.cmu.edu> Subject: RE: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-iddiscovery process Date: Tue, 19 Jun 2007 20:00:32 -0400 Message-ID: <06d901c7b2ce$07125ec0$0600a8c0@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: <560465D5DCE4E968F0FC3AA7@sirius.fac.cs.cmu.edu> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-index: AceZlCneiM0YWiheTSa9iDsXtryx5gZFxfFA X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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, I think it might be useful to permit netconf and snmp to use different channels over the same connection, and this would presumably allow that. It might also be a simpler way of differentiating R/R traffic from Notifications. I can change this in the SSH transport model, but I'm not sure we have consensus on this point yet. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Friday, May 18, 2007 5:33 PM > To: David Harrington; 'tom.petch' > Cc: isms@ietf.org; Jeffrey Hutzelman > Subject: RE: TMSM and Port was Re: [Isms] Question regarding > SNMPv3engine-iddiscovery process > > > > On Friday, May 18, 2007 04:54:38 PM -0400 David Harrington > wrote: > > > I'm afraid I don't see the benefit of this extension. Can you > > enlighten me? > > The idea is to allow multiplexing of traffic by SSH subsystem > name, rather > than by TCP port number. I thought this might be interesting > to the people > who were concerned about only having one default port. Let's > see if anyone > else thinks this would be useful; if not, we can just drop it. > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 20 01:51:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0t5v-0003PG-DR; Wed, 20 Jun 2007 01:51:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0t5t-0003PA-LZ for isms@ietf.org; Wed, 20 Jun 2007 01:51:05 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0t5s-0003JP-2V for isms@ietf.org; Wed, 20 Jun 2007 01:51:05 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 308C784B78; Wed, 20 Jun 2007 07:51:03 +0200 (CEST) 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 28216-03; Wed, 20 Jun 2007 07:50:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09A7784A01; Wed, 20 Jun 2007 07:50:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5768929AC14; Wed, 20 Jun 2007 07:50:55 +0200 (CEST) Date: Wed, 20 Jun 2007 07:50:55 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: TMSM and Port was Re: [Isms] Question regarding SNMPv3engine-iddiscovery process Message-ID: <20070620055055.GA26625@elstar.local> Mail-Followup-To: David Harrington , 'Jeffrey Hutzelman' , "'tom.petch'" , isms@ietf.org References: <013901c7873b$4025fc80$0601a8c0@pc6> <01f501c7874d$cd22a5e0$0600a8c0@china.huawei.com> <05bd01c788e7$ff4ce1c0$0601a8c0@pc6> <6328B76F92A0AE1C0068C68F@sirius.fac.cs.cmu.edu> <020301c79986$e155c330$0600a8c0@china.huawei.com> <450809FCECF0B4F4E1695A99@sirius.fac.cs.cmu.edu> <024d01c7998e$c01ab510$0600a8c0@china.huawei.com> <560465D5DCE4E968F0FC3AA7@sirius.fac.cs.cmu.edu> <06d901c7b2ce$07125ec0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06d901c7b2ce$07125ec0$0600a8c0@china.huawei.com> 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.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org, 'Jeffrey Hutzelman' 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 Tue, Jun 19, 2007 at 08:00:32PM -0400, David Harrington wrote: > I think it might be useful to permit netconf and snmp to use different > channels over the same connection, and this would presumably allow > that. It might also be a simpler way of differentiating R/R traffic > from Notifications. Talking as implementor, I consider NETCONF and SNMP using different channels over the same SSH connection a rather academic construction. /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 Jun 25 19:50:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2yKa-0004rC-Le; Mon, 25 Jun 2007 19:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2yKZ-0004r5-G0 for isms@ietf.org; Mon, 25 Jun 2007 19:50:51 -0400 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2yKX-0002nw-Sr for isms@ietf.org; Mon, 25 Jun 2007 19:50:51 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc13) with SMTP id <20070625235048m1300abncge>; Mon, 25 Jun 2007 23:50:48 +0000 From: "David Harrington" To: "'tom.petch'" , References: <033d01c792c5$9154b9d0$0600a8c0@china.huawei.com> <000401c793e7$a5677de0$0601a8c0@pc6> <20070520192122.GB26568@elstar.local> <005601c79b7e$df8d1c20$0601a8c0@pc6> Subject: RE: [Isms] draft-ietf-isms-tmsm-08.txt Date: Mon, 25 Jun 2007 19:50:16 -0400 Message-ID: <023701c7b783$97511260$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acebh8kXv7tX3UKmRQy0U+AAdpogzAb3e+NA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <005601c79b7e$df8d1c20$0601a8c0@pc6> X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 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, >From Tom: "There are two types of authentication, data origin authentication and peer entity authentication [RFC2828/draft-shirey-secgloss]." Actually, there are more than just data origin authentication and peer authentication. Merriam-Webster defines authentication this way: "to prove or serve to prove the authenticity of ". I added text to the Conventions section that says where necessary for consistency with related documents, this document favors terminology consistent with the IETF SNMPv3 Standard (STD62) rather than the informational 'Internet Security Glossary' (RFC2828). USM achieved Proposed Standard Status in 1998, Draft Standard status in 1999, and full Standard status in 2002. In comparison, RFC2828 is an Informational document, and it was published AFTER USM had already become a Draft Standard. The IESG decided it was not worth rewriting all of the RFC341x series to be compatible with RFC2828. Even RFC2828 recognizes that it is using the term authentication in a manner not consistent with accepted English usage. Don't fault SNMP for using the accepted English meaning just because RFC2828 decided after the fact to use the same word to refer to only a subset of the legitimate usage. We do not blur the meaning of authentication; RFC2828 does that disservice just fine on its own. ;-) In SNMPv3, we "authenticate the message" - we attempt to prove the authenticity of the message, not just the authenticity of the peer. In SNMPv3, we authenticate the message partly by authenticating the principal (the sender of the message, not the sender of the data), using whatever authentication protocol has been configured to authenticate that principal. We also verify that the message is authentic by checking that the message has not been modified, we check that the message contains a timestamp that is consistent with the receiver's notion of the time at the message sender (within a time window) to prevent replay, and for responses, SNMPv3 checks to see whether we are awaiting a response. All of these go into the SNMPv3 notion of "authenticating the message". We never explicitly authenticate the data or the original source of the data; we may assume that the source of the data and the source of the message are the same when contextEngineID == securityEngineID, but we never authenticate the contextEngineID, and we do not pass a contextSecurityName to identify the principal providing the data, and we provide no mechanisms for authenticating the data contained in the PDU, only the message that contains the PDU. When doing the "proxy forwarder" application described in RFC3413, the trust relationship is considered transitive, and the PDU (including the contextEngineID) is never modified by a compliant proxy forwarder. So, if A has a trust relationship with B, and B has a trust relationship with C, and C has a trust relationship with D, and each node verifies the authenticity of the message received from its peer, then a message from A to B to C to D can be deemed to be "authentic". In SNMPv3, we deliberately identified the threats that must be mitigated, but we did not specify HOW different security mechanisms needed to mitigate the threats; the modular architecture is designed to permit different security models, and different security mechanisms, and accepts that different models and mechanisms might perform threat mitigation in different ways. SNMPv3 recognizes two general categories of security services - authentication of the message, and encryption of all or part of the message. Verifying the integrity of the message, verifying the timeliness or in-order-ness of the message, and authenticating the sending principal are all considered part of "authenticating the message". We want to have the discussions about what threats SSH (or any other secure transport) should mitigate when used with SNMP, and whether there are specific operational considerations to ensure that the threat is not inadvertently not mitigated (e.g., recommend not using options to not check integrity, or to not authenticate the user). SSH adequately provides mitigation for the security threats that RFC3411 identifies as threats to SNMP, even though SSH uses a different model and mechanisms to provide that mitigation than USM. SSH authenticates the "user" (the source of the message, not necessarily the source of the data), and it checks for message integrity and message replay. It does NOT check for receipt within a time window (to my knowledge); I believe it requires in-order delivery to prevent replay. Rather than checking user authenticity for every message, it performs user authentication once and holds that the authentication remains true as long as the connection is not interrupted - i.e., the session exchange hash remains unchanged. We do not want to get into discussions of these details of how SSH works - that should be done by the SSH mechanisms used to provide "message authentication". The RFC3411 architecture and the SNMPv3 message processing model are pretty clear about the fact they do not know about the details of the security models or the authentication mechanisms; the data in the msgSecurityParameters of the SNMPv3 message are only examined by the security model, and it asserts that the message has been "proved" authentic. The SSH authentication protocol (RFC4252 "The Secure Shell (SSH) Authentication Protocol") describes how message authentication is done - by relying on message integrity and confidentiality services of the lower layer transport, by using a session hash, and tying the peer authetication to the session hash. We do not want to prevent the use of new authentication mechanisms for SSH by over-describing how "authenticating the message" is expected to be done, or how peer authentication is performed, or what assumptions are utilized in the secure transport protocol. We should not add rules to TMSM about the user authentication being valid only as long as the underlying transport connection remains; that is a design choice of some secure transport authentication mechanisms (like SSH-USER-AUTH) that may not always be true for all secure transport authentication mechanisms in the future. SNMP already has more than enough CLRs without inventing new ones here. dbh > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Monday, May 21, 2007 3:58 AM > To: j.schoenwaelder@jacobs-university.de > Cc: David Harrington; isms@ietf.org > Subject: Re: [Isms] draft-ietf-isms-tmsm-08.txt > > > Tom Petch > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "tom.petch" > Cc: "David Harrington" ; > Sent: Sunday, May 20, 2007 9:21 PM > Subject: Re: [Isms] draft-ietf-isms-tmsm-08.txt > > > > On Fri, May 11, 2007 at 06:11:38PM +0200, tom.petch wrote: > > > > > I have a concern with this I-D that it is blurring the meaning of > > > authentication As per RFC2828, there is data origin authentication > > > and peer entity authentication. Read the secure session RFC, such > > > as SSH and TLS, and they are clear that they offer peer entity > > > authentication.and not data origin authentication. This I-D, like > > > the RFC341? series, seems to be written as if there were only data > > > origin authentication, as if authentication was a > security function > > > that will applied to an isolated message, as opposed to occurring > > > only in the context of an association. Rather, with Transport > > > Security, the message cannot be authenticated; it came over a pipe > > > from a peer which was authenticated some time in the past and the > > > authentication depends on the continued existence of that > pipe. In > > > security terms, I see the difference as significant and one that > > > this I-D should call out. > > > > Good point. However, I have the feeling that the SNMPv3 > specifications > > have never been very consistent about this as they generally promise > > data origin authentication but I think data origin authentication is > > not what is actually delivered in the case of proxies. Do you agree > > with me here? > > > Yes, I am not sure how I would classify the authentication > delivered by > proxies:-) > > My main line of thought is to insert a section such as the > following - my style > is a little different to yours and those with a greater > knowledge of security > than I may want to tweak the terminology - before the existing 3.3.3 > > =========================================== > There are two types of authentication, data origin > authentication and peer > entity authentication [RFC2828/draft-shirey-secgloss]. In the > former, each > message is individually authenticated using the security > credentials. This > technique is used in SMTP [RFC3851] and in USM [RFC3414]; > in fact, parts of the specification of SNMP is written as if > this were the only > type of authentication [RFC3411, RFC3412]. > > With peer entity authentication, the identity of a peer is > authenticated, a > secure tunnel (channel, session) is set up with that peer and > keying materials > are created for use with that tunnel. Individual messages > may be encrypted or > integrity checked but are not authenticated. Rather, > authentication depends on > the fact that the message arrived over the secure tunnel the > endpoint of which > was authenticated when the tunnel was set up, which may be a > long time ago. This > approach is used by SSH [RFC4251] and TLS[RFC4346] and so by > applications such > as HTTPS [RFC2818] and NETCONF [RFC4742]. > > The use of transport security by SNMP brings the use of peer entity > authentication and so the wording used by previous documents > must be interpreted > in that light. A Transport Security Model using SSH or TLS > may be able to > check that the tunnel over which a message arrived is known > and so that the peer > has been authenticated but cannot meaningfully be said to > authenticate an > individual message. Rather, authentication depends on the > procedures followed > when the tunnel was created. > > ================================================= > > In 3.2.1.2, I would put 'authenticate' in quotes with a cross > reference to the > above. > > In 3.2.3, I would add to the second paragraph a parenthetic > comment 'The > different types of authentication are describe in ' with a > cross reference to > the above. > > In 3.3.3, I would change > "authentication, integrity checking, and encryption services for data" > > "integrity checking, encryption and, perhaps, authentication > for data". > > (After all, the key exchange could derive a key that is used > to authenticate > individual messages in addition to the peer entity > authentication although I > know of no current system that does so). > > Also, in 3.2.1.3, I would change > > "establish an authenticated and/or encrypted tunnel between > the Transport > Models" > to disallow encrypted unauthenticated which the use of and/or > currently permits. > > At which point I would re-read the document to see how it all > hangs together. > > Tom Petch > > > Still, we can do better and should get the text straight. > If you have > > concrete proposals how to change the wording in the > affected sections, > > I am sure Dave will be more than happy to pick them up. > > > > /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 Wed Jun 27 17:58:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fXH-000256-RD; Wed, 27 Jun 2007 17:58:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fXH-000250-4Q for isms@ietf.org; Wed, 27 Jun 2007 17:58:51 -0400 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3fXG-0006Fy-VK for isms@ietf.org; Wed, 27 Jun 2007 17:58:51 -0400 Received: from newton603 (c-24-61-11-96.hsd1.nh.comcast.net[24.61.11.96]) by comcast.net (sccrmhc12) with SMTP id <20070627215818012003l3c5e>; Wed, 27 Jun 2007 21:58:18 +0000 From: "David B. Nelson" To: Date: Wed, 27 Jun 2007 17:58:44 -0400 Message-ID: <00ff01c7b906$548ce290$6401a8c0@NEWTON603> 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.3138 Thread-Index: Ace5BlRFGq4GH77dR7qBCJYvxLKkMA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Isms] Comments on draft-ietf-isms-secshell-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 In section 3.1.3: It is also possible to use a different password validation protocol such as CHAP [RFC1994] or digest authentication [RFC 2617, draft-ietf-radext-digest-auth-04] to integrate with RADIUS or Diameter. These mechanisms leave the password in the clear on the device that is authenticating the password which introduces threats to the authentication infrastructure. Note that draft-ietf-radext-digest-auth-04 has been published as RFC 4590. This is currently under revision, to fix a couple or errors, as draft-ietf-radext-rfc4590bis-01.txt. In the second sentence I would recommend changing "leave" to "require". _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Jun 27 18:18:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fpx-00062J-Q8; Wed, 27 Jun 2007 18:18:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fpw-0005xC-Sw for isms@ietf.org; Wed, 27 Jun 2007 18:18:08 -0400 Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3fpP-0004yG-VL for isms@ietf.org; Wed, 27 Jun 2007 18:18:08 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc15) with SMTP id <20070627221734m15009f5s8e>; Wed, 27 Jun 2007 22:17:34 +0000 From: "David Harrington" To: "'David B. Nelson'" , References: <00ff01c7b906$548ce290$6401a8c0@NEWTON603> Subject: RE: [Isms] Comments on draft-ietf-isms-secshell-07.txt Date: Wed, 27 Jun 2007 18:17:12 -0400 Message-ID: <051e01c7b908$e9b245c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ace5BlRFGq4GH77dR7qBCJYvxLKkMAAAUpWg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <00ff01c7b906$548ce290$6401a8c0@NEWTON603> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 am of the impression that implementers can encrypt their own storage of the password, so I don't see "require" or "leave" as accurate. How about, "At some point during the processing, these mechanisms require the password be made available as cleartext on the device ... which might introduce ...". dbh > -----Original Message----- > From: David B. Nelson [mailto:d.b.nelson@comcast.net] > Sent: Wednesday, June 27, 2007 5:59 PM > To: isms@ietf.org > Subject: [Isms] Comments on draft-ietf-isms-secshell-07.txt > > In section 3.1.3: > > It is also possible to use a different > password validation protocol such as CHAP [RFC1994] or digest > authentication [RFC 2617, draft-ietf-radext-digest-auth-04] to > integrate with RADIUS or Diameter. These mechanisms leave the > password in the clear on the device that is authenticating the > password which introduces threats to the authentication > infrastructure. > > Note that draft-ietf-radext-digest-auth-04 has been published > as RFC 4590. > This is currently under revision, to fix a couple or errors, as > draft-ietf-radext-rfc4590bis-01.txt. > > In the second sentence I would recommend changing "leave" to > "require". > > > > > _______________________________________________ > 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 27 18:23: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 1I3fup-0004nM-Sn; Wed, 27 Jun 2007 18:23:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3fuo-0004nG-Ix for isms@ietf.org; Wed, 27 Jun 2007 18:23:10 -0400 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3fuo-0007n8-At for isms@ietf.org; Wed, 27 Jun 2007 18:23:10 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc13) with SMTP id <20070627222236m130051it9e>; Wed, 27 Jun 2007 22:22:37 +0000 From: "David Harrington" To: "'David B. Nelson'" , References: <00ff01c7b906$548ce290$6401a8c0@NEWTON603> Subject: RE: [Isms] Comments on draft-ietf-isms-secshell-07.txt Date: Wed, 27 Jun 2007 18:22:15 -0400 Message-ID: <052d01c7b909$9e215fa0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ace5BlRFGq4GH77dR7qBCJYvxLKkMAAArr7g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <00ff01c7b906$548ce290$6401a8c0@NEWTON603> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 updated the reference to RFC4590, which I think is sufficient at this point. dbh > -----Original Message----- > From: David B. Nelson [mailto:d.b.nelson@comcast.net] > Sent: Wednesday, June 27, 2007 5:59 PM > To: isms@ietf.org > Subject: [Isms] Comments on draft-ietf-isms-secshell-07.txt > > In section 3.1.3: > > It is also possible to use a different > password validation protocol such as CHAP [RFC1994] or digest > authentication [RFC 2617, draft-ietf-radext-digest-auth-04] to > integrate with RADIUS or Diameter. These mechanisms leave the > password in the clear on the device that is authenticating the > password which introduces threats to the authentication > infrastructure. > > Note that draft-ietf-radext-digest-auth-04 has been published > as RFC 4590. > This is currently under revision, to fix a couple or errors, as > draft-ietf-radext-rfc4590bis-01.txt. > > In the second sentence I would recommend changing "leave" to > "require". > > > > > _______________________________________________ > 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 Jun 28 08:19: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 1I3syK-0003z2-00; Thu, 28 Jun 2007 08:19:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3syG-0003wE-Bt for isms@ietf.org; Thu, 28 Jun 2007 08:19:36 -0400 Received: from sccrmhc13.comcast.net ([204.127.200.83]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3syG-0001Aw-6h for isms@ietf.org; Thu, 28 Jun 2007 08:19:36 -0400 Received: from newton603 (c-24-61-11-96.hsd1.nh.comcast.net[24.61.11.96]) by comcast.net (sccrmhc13) with SMTP id <20070628121911013005mhrve>; Thu, 28 Jun 2007 12:19:11 +0000 From: "David B. Nelson" To: References: <00ff01c7b906$548ce290$6401a8c0@NEWTON603> <051e01c7b908$e9b245c0$0600a8c0@china.huawei.com> Subject: RE: [Isms] Comments on draft-ietf-isms-secshell-07.txt Date: Thu, 28 Jun 2007 08:19:37 -0400 Message-ID: <013901c7b97e$98a645c0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <051e01c7b908$e9b245c0$0600a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace5BlRFGq4GH77dR7qBCJYvxLKkMAAAUpWgAB2lR8A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 am of the impression that implementers can encrypt their own storage > of the password ... Yes, reversible encryption of the password would be possible, while a hash would not. > How about, > > "At some point during the processing, these mechanisms require the > password be made available as cleartext on the device ... which might > introduce ...". Sure. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Jun 28 12:34:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3wws-0007hV-5l; Thu, 28 Jun 2007 12:34:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3wwr-0007gg-24 for isms@ietf.org; Thu, 28 Jun 2007 12:34:25 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3wvz-00028n-Aq for isms@ietf.org; Thu, 28 Jun 2007 12:34:25 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc11) with SMTP id <20070628163330m11000cghke>; Thu, 28 Jun 2007 16:33:30 +0000 From: "David Harrington" To: "'David B. Nelson'" , References: <00ff01c7b906$548ce290$6401a8c0@NEWTON603><051e01c7b908$e9b245c0$0600a8c0@china.huawei.com> <013901c7b97e$98a645c0$6401a8c0@NEWTON603> Subject: RE: [Isms] Comments on draft-ietf-isms-secshell-07.txt Date: Thu, 28 Jun 2007 12:33:07 -0400 Message-ID: <059701c7b9a2$02acad60$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ace5BlRFGq4GH77dR7qBCJYvxLKkMAAAUpWgAB2lR8AABGVW4A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <013901c7b97e$98a645c0$6401a8c0@NEWTON603> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 done. > -----Original Message----- > From: David B. Nelson [mailto:d.b.nelson@comcast.net] > Sent: Thursday, June 28, 2007 8:20 AM > To: isms@ietf.org > Subject: RE: [Isms] Comments on draft-ietf-isms-secshell-07.txt > > David Harrington writes... > > > I am of the impression that implementers can encrypt their > own storage > > of the password ... > > Yes, reversible encryption of the password would be possible, > while a hash > would not. > > > How about, > > > > "At some point during the processing, these mechanisms require the > > password be made available as cleartext on the device ... > which might > > introduce ...". > > Sure. > > > > > _______________________________________________ > 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