From isms-bounces@ietf.org Tue Apr 1 13:46:40 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5153328C12E; Tue, 1 Apr 2008 13:46:40 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421A23A69F1 for ; Tue, 1 Apr 2008 13:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=0.893, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id si+XIShwknaq for ; Tue, 1 Apr 2008 13:46:31 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id AA4B928C5DE for ; Tue, 1 Apr 2008 13:46:17 -0700 (PDT) Received: (qmail 19524 invoked from network); 1 Apr 2008 15:46:15 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 1 Apr 2008 15:46:15 -0400 From: "David B. Nelson" To: "'David Harrington'" , References: <00d701c89389$9f805710$0600a8c0@china.huawei.com> Date: Tue, 1 Apr 2008 15:44:15 -0400 Organization: Elbrys Networks, Inc. Message-ID: <001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <00d701c89389$9f805710$0600a8c0@china.huawei.com> Thread-Index: AciTiZ79SOFZmNc6RJWNJ4eQ2H0HlQAl2/Ig Subject: Re: [Isms] WGLC: draft-ietf-isms-radius-usage-02 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington writes... > I have reviewed this document. Comments below. Thank you for your thorough review. I will respond to those issues that are easily resolved and highlight those which require further thought or discussion. > I found the document a little hard to read because background info on > RADIUS, info on the management-policy-id related attributes, and the > mapping to SNMP are all mushed together. This is something that will require further thought. The authors added the introductory material in response to your comments on a previous version. A plan to more clearly delineate the various elements will require some time spent in re-reading the material with an eye toward that objective. > In discussing the mapping to SNMP, PLEASE assume that the > management-policy-id has already been accepted by the IETF. Sure. > That means a lot of the phrases like "RADIUS servers compliant to this > specification" can just be reduced to "RADIUS servers". I think you misunderstand the intent of that phrase. It has nothing to do with the status of the document (draft or published RFC) and everything to do with the fact that there is no monolithic RADIUS Standard. There is the base RADIUS protocol and there are number of optional extensions, supporting specific applications. > So, I recommend the document have sections 1) introduction to standard > RADIUS, 2) introduction to the management-policy-id and related > attributes, and THEN discuss the mapping to SNMP (Actually, I would be > fine with having the first two combined or possibly eliminated). Well, as to the possibility of eliminating the introductory material, it's largely there at your request. :-) > I think this document should be written as one of multiple mapping > documents for the management-policy-id and related attributes, and it > should be expected that a mapping document will be done at some point > for Netconf, the CLI, and potentially other interfaces. Hmmm. That sounds like scope-creep. I agree that we should avoid creating any gratuitous SNMP-specific dependencies, but this document is about RADIUS and SNMP, not about RADIUS and anything else. Right? > 1. I recommend moving the "Requirements language" text into a section, > possibly under Introduction. I'll need to review the draft to identify this text, but the suggestion sounds very reasonable. > section 1.1 - we don't have modules in ISMS, we have models and > subsystems. I always think I've got rid of the last of those, but I probably introduce new ones at the same time as eliminating old ones. :-) We'll take care of this. > section 1.2 says "An Access-Reject message indicates unsuccessful > authentication." Does it also indicate an unsuccessful authorization? Yes. > section 2 says > "Service authorization allows a RADIUS server to authorize an > authenticated principal to use SNMP over a specific secure > Transport Model. > I think that is incorrect. The attributes we intend to use here > authorize the use of a service for Framed-Management, the > Framed-Management-Protocol to use (SNMP), a Management-Policy-ID (such > as "Operator"), and a level of Transport-Protection. Yes. That's a mouthful (run-on sentence) but that's really what's meant. > section 2 discusses PAM; how do RADIUS servers in a Windows > environment do this? PAM is an interface between an end-user data service (e.g. SSH) and an authentication service (e.g. RADIUS Client). RADIUS Servers do not come into the picture. PAM is common in Unix environments. I don't know what the equivalent is in a Windows environment. > s/rely of/rely on/ OK. > section 2.1 > "Specific attributes for use with SNMP Transport Models are > recommended in this document." I don't think this document should be > used to make recommendations of specific RADIUS attributes. This > document should simply be about how to use the management-related > attributes that are defined, in an SNMP environment. Huh? You want this document to describe how to use RADIUS for authentication and authorization of SNMP access without mentioning specific RADIUS attributes? I know that SNMP documentation and architecture is big on abstraction, models, and such. RADIUS documentation doesn't go in for that sort of thing, for better or worse. I wouldn't know where to begin... > s/"RADIUS servers, compliant to this specification, MAY use RADIUS > hint attributes, as described herein, to inform the decision whether > to accept or reject the authentication request."/ > "RADIUS servers MAY use RADIUS hint attributes to inform the > decision whether to accept or reject the authentication request."/ OK. You don't like my overly-formal language. I can live with that. > (but isn't the hint really part of an authorization request rather > than an authentication request? You can't really separate the two in RADIUS, as much as one might like to. I know this has been an issue in the ISMS work, but RADIUS is a legacy protocol and "it is what it is". > I might be able to authenticate who I am, but still not get approval > to access the SNMP service.") That's true. In that case one of two things would happen. The RADIUS Server would return an Access-Accept message provisioning a default service for your profile that you are authorized to use, or more likely the RADIUS Server would return an Access-Reject message, because you are not authorized to use the service you are apparently requesting. > section 2.2 eliminate the sentence > " Specific attributes for use with SNMP Transport Models are > recommended in this document." This gets back to my previous question. Are you effectively asking the authors to create an abstract "model" of how RADIUS might interact with SNMP? I don't think that's what we have been tasked to produce. If that's not what you're asking of us, what is your concern with specificity? > " The following RADIUS attributes MAY be optionally used, to > authorize use of SNMP over the default UDP transport protocol (no > privacy):" > What transport model calls RADIUS to authenticate a UDP session? This > is news to me. Hmmm. That looks wrong. I forget where that came from, but it will be removed. > " The following RADIUS attributes are used to limit the extent of a > secure transport session carrying SNMP traffic, in conjunction with > an SNMP Transport Model: > > 1. Session-Timeout > 2. Inactivity-Timeout." > What transport model does this? Well, I'm not sure any of them do... more like they should. I think this needs some discussion. > I think this is between RADIUS and the transport protocol that is > using RADIUS, such as SSH. Quite possibly. > I don't think SNMP has anything to do with this, and there is no > place in the ISMS architecture to specify these values. There may not be a place in the ISMS architecture. However, RADIUS has a long history of provisioning limits on the services that it authorizes, so it seemed natural to continue this practice with SNMP. > I am not sure they should be discussed in this document. If not here, then where? > Is this Inactivity-Timeout related to the Idle-Timeout mentioned > later? Yes. > section 2.4. I think the authorization attributes provided by RADIUS > should probably be captured as part of the LCD, as part of > transport-specific information. I don't understand. > section 3 should be part of the introduction to RADIUS and the > management related attributes. It seems out of place here. Well, in RADIUS documents there is always a Table of Attributes near the end of the document, just before such sections as the Security Considerations. In case it's not already apparent, the authors are following RADIUS document style and not SNMP document style. > section 5 > s/Threats and security issues for > this application are described in [RFC3579] and [RFC3580]; " > /Threats and security issues for > RADIUS are described in [RFC3579] and [RFC3580];/ OK. > Paragraph three discusses selecting SNMPv1 and SNMPv2c. I think the > discussion of using RADIUS with these needs further discussion. OK. I'm sure I got this text from some posting on the ISMS list, but I'm not sure it's correct or complete. > Currently, SNMPv1 can be used with an SSH tunnel, with no transport > model to provide a binding; we might develop a transport model with a > binding. The RADIUS attributes for management, however, may not allow > us to choose which transport model or even which transport protocol, > and under those conditions, I don't know what we have for security > with an SNMPv1 or SNMPv2c (or SNMPv3) message, since we may have no > transport model to provide a mapping between the transport layer > credentials and the SNMP-specific securityModel/Name/Level. > > The "this may not be expected" would probably be better phrased as > "the authenticated identity used for securityName will not be the > identity authenticated by RADIUS". OK. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Apr 1 14:22:19 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0BBC3A6C35; Tue, 1 Apr 2008 14:22:19 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF173A6BC8 for ; Tue, 1 Apr 2008 14:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Un00+DDoQEid for ; Tue, 1 Apr 2008 14:22:17 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 99C393A68DC for ; Tue, 1 Apr 2008 14:22:17 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m31LM7p9001929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Apr 2008 17:22:07 -0400 (EDT) Date: Tue, 01 Apr 2008 17:22:07 -0400 From: Jeffrey Hutzelman To: "David B. Nelson" , "'David Harrington'" , isms@ietf.org Message-ID: In-Reply-To: <001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2> References: <00d701c89389$9f805710$0600a8c0@china.huawei.com> <001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] WGLC: draft-ietf-isms-radius-usage-02 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Tuesday, April 01, 2008 03:44:15 PM -0400 "David B. Nelson" wrote: >> section 2 discusses PAM; how do RADIUS servers in a Windows >> environment do this? > > PAM is an interface between an end-user data service (e.g. SSH) and an > authentication service (e.g. RADIUS Client). RADIUS Servers do not come > into the picture. PAM is common in Unix environments. I don't know what > the equivalent is in a Windows environment. To be fair, it is also reasonable for a RADIUS server to use PAM for password verification, allowing any of a variety of backends to be plugged in. But as far as the protocol is concerned, that's an implementation detail. For that matter, the use of PAM between an SSH server and RADIUS client is also an implementation detail. It's possible that an SSH server uses PAM to support the password or keyboard-interactive auth methods, and if so, it's possible that the PAM stack is configured to use RADIUS. The fact that we mention this possibility in a couple of places does not mean we are obligated to describe every way in which an SSH server might end up being a RADIUS client. I don't think any change is needed here. >> section 2.1 >> "Specific attributes for use with SNMP Transport Models are >> recommended in this document." I don't think this document should be >> used to make recommendations of specific RADIUS attributes. This >> document should simply be about how to use the management-related >> attributes that are defined, in an SNMP environment. > > Huh? You want this document to describe how to use RADIUS for > authentication and authorization of SNMP access without mentioning > specific RADIUS attributes? I know that SNMP documentation and > architecture is big on abstraction, models, and such. RADIUS > documentation doesn't go in for that sort of thing, for better or worse. > I wouldn't know where to begin... I think I have to agree with David here. :-) The point of this document is to describe how to use RADIUS to authorize SNMP access. I don't see how we can do that without indicating which RADIUS attributes are used for that purpose and what they mean. We could write a document which describes some abstraction for allowing SNMP applications to see whatever attributes happened to be provided by the RADIUS server, but I don't think that would accomplish our goal for this document. >> I don't think SNMP has anything to do with this, and there is no >> place in the ISMS architecture to specify these values. > > There may not be a place in the ISMS architecture. However, RADIUS has a > long history of provisioning limits on the services that it authorizes, so > it seemed natural to continue this practice with SNMP. I agree. Note that the SNMP architecture doesn't necessarily need to have any place to specify these limits. This can be handled entirely at the SSH layer. And yes, I do think this document is the right place to discuss such things. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Apr 1 15:39:15 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 863083A6E08; Tue, 1 Apr 2008 15:39:15 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A66C3A6DBE for ; Tue, 1 Apr 2008 15:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRhKfG4YcWCD for ; Tue, 1 Apr 2008 15:39:13 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 0D0FA3A6A9D for ; Tue, 1 Apr 2008 15:39:13 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 01 Apr 2008 15:39:12 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m31MdCeV013568; Tue, 1 Apr 2008 15:39:12 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m31MdCkQ003221; Tue, 1 Apr 2008 22:39:12 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 15:39:11 -0700 Received: from 171.69.75.173 ([171.69.75.173]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Tue, 1 Apr 2008 22:39:10 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 01 Apr 2008 15:39:10 -0700 From: Kaushik Narayan To: "David B. Nelson" , "'David Harrington'" , Message-ID: Thread-Topic: [Isms] WGLC: draft-ietf-isms-radius-usage-02 Thread-Index: AciTiZ79SOFZmNc6RJWNJ4eQ2H0HlQAl2/IgAAoJNzU= In-Reply-To: <001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2> Mime-version: 1.0 X-OriginalArrivalTime: 01 Apr 2008 22:39:11.0214 (UTC) FILETIME=[345DB8E0:01C89449] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4856; t=1207089552; x=1207953552; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20Kaushik=20Narayan=20 |Subject:=20Re=3A=20[Isms]=20WGLC=3A=20draft-ietf-isms-radi us-usage-02 |Sender:=20; bh=5w9hv+Ba72aNR6TsZ7ZJN19mr+5aoTqvkVoQmgvvrrg=; b=IVlRwmvRgnPFm2wnZ9lYp9JeO7z91qBSEsXeYwKwmRQejP7Se6W9Vmq8TH 4sJM0LP8AzfBht46APqBFiI8XUiXjWoxHX7T/2e58ewavNaedM7godZHLEQr CptzjMfF5l; Authentication-Results: sj-dkim-3; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Isms] WGLC: draft-ietf-isms-radius-usage-02 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Please find my reply inline. On 4/1/08 12:44 PM, "David B. Nelson" wrote: > David Harrington writes... > >> I have reviewed this document. Comments below. > > Thank you for your thorough review. I will respond to those issues that are > easily resolved and highlight those which require further thought or > discussion. > >> I found the document a little hard to read because background info on >> RADIUS, info on the management-policy-id related attributes, and the >> mapping to SNMP are all mushed together. > > This is something that will require further thought. The authors added the > introductory material in response to your comments on a previous version. A > plan to more clearly delineate the various elements will require some time > spent in re-reading the material with an eye toward that objective. The introductory text is brief to ensure that we do not end up copying significant parts of other RFCs and drafts. We probably should avoid significant work in this area unless people believe that the rest of the specification is unclear because of missing context in the introduction. > > >> I think this document should be written as one of multiple mapping >> documents for the management-policy-id and related attributes, and it >> should be expected that a mapping document will be done at some point >> for Netconf, the CLI, and potentially other interfaces. > > Hmmm. That sounds like scope-creep. I agree that we should avoid creating > any gratuitous SNMP-specific dependencies, but this document is about RADIUS > and SNMP, not about RADIUS and anything else. Right? I agree with David, the approach described in the document could be applied to other management protocols such as NetConf etc. but that is not the purpose of this document. > >> section 2 discusses PAM; how do RADIUS servers in a Windows >> environment do this? > > PAM is an interface between an end-user data service (e.g. SSH) and an > authentication service (e.g. RADIUS Client). RADIUS Servers do not come > into the picture. PAM is common in Unix environments. I don't know what > the equivalent is in a Windows environment. > The reference to PAM was meant to highlight some of the issues with existing implementations where the OS-specific interfaces are used by SSHv2 implementations to integrate with the RADIUS client. This potentially complicates how RADIUS attributes received by the RADIUS client are made available to the SNMP layer. PAM was merely used as an example and the intent was not to list each OS-specific interface. >> I might be able to authenticate who I am, but still not get approval >> to access the SNMP service.") > > That's true. In that case one of two things would happen. The RADIUS > Server would return an Access-Accept message provisioning a default service > for your profile that you are authorized to use, or more likely the RADIUS > Server would return an Access-Reject message, because you are not authorized > to use the service you are apparently requesting. Service authorization is a coarse granular method to ensure that access to the SNMP service is limited to operators/administrators, the RADIUS server would probably be capable of authenticating the entire set of user's within an organization. > >> " The following RADIUS attributes are used to limit the extent of a >> secure transport session carrying SNMP traffic, in conjunction with >> an SNMP Transport Model: >> >> 1. Session-Timeout >> 2. Inactivity-Timeout." >> What transport model does this? > > Well, I'm not sure any of them do... more like they should. I think this > needs some discussion. > >> I think this is between RADIUS and the transport protocol that is >> using RADIUS, such as SSH. > > Quite possibly. > >> I don't think SNMP has anything to do with this, and there is no >> place in the ISMS architecture to specify these values. > > There may not be a place in the ISMS architecture. However, RADIUS has a > long history of provisioning limits on the services that it authorizes, so > it seemed natural to continue this practice with SNMP. > >> I am not sure they should be discussed in this document. > > If not here, then where? Session timers and inactivity timers are commonly used for CLI access for administration (with RADIUS/TACACS+). The timers may be used by the transport protocol (sshd, telnetd) or the application spawned (shell/terminal). I agree with David that this fairly common and needs more discussion before we dismiss it. Regards, kaushik _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Apr 1 18:54:15 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E12EC3A6B76; Tue, 1 Apr 2008 18:54:15 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5C83A6B76 for ; Tue, 1 Apr 2008 18:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVWK3QfEK1zO for ; Tue, 1 Apr 2008 18:54:13 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 707843A69F4 for ; Tue, 1 Apr 2008 18:54:10 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA09.westchester.pa.mail.comcast.net with comcast id 8GvF1Z0090mv7h0590aj00; Wed, 02 Apr 2008 01:52:31 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.westchester.pa.mail.comcast.net with comcast id 8Ru21Z00E4HwxpC3X00000; Wed, 02 Apr 2008 01:54:05 +0000 X-Authority-Analysis: v=1.0 c=1 a=gXomjMozV1QeAHrU7ZAA:9 a=tpfhvDnSENG_NkNzd4QA:7 a=lTm6Og6Cbgb4Mx-c9TCQrM_74OcA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'David B. Nelson'" , References: <00d701c89389$9f805710$0600a8c0@china.huawei.com> <001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2> Date: Tue, 1 Apr 2008 21:54:02 -0400 Message-ID: <017101c89464$6d185210$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2> thread-index: AciTiZ79SOFZmNc6RJWNJ4eQ2H0HlQAl2/IgAAW7hyA= Subject: Re: [Isms] WGLC: draft-ietf-isms-radius-usage-02 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, comments inline. dbh > > I think this document should be written as one of multiple mapping > > documents for the management-policy-id and related > attributes, and it > > should be expected that a mapping document will be done at > some point > > for Netconf, the CLI, and potentially other interfaces. > > Hmmm. That sounds like scope-creep. I agree that we should > avoid creating > any gratuitous SNMP-specific dependencies, but this document > is about RADIUS > and SNMP, not about RADIUS and anything else. Right? Sorry. I didn't mean to be misleading with this. I am not proposing that ISMS write such documents. I am only suggesting that the design of the document should be that it is specifically an SNMP mapping to these documents, as if there were also CLI mapping documents and Netconf mapings documents, etc. The goal is to make this document clearly focused on the mapping. > > > 1. I recommend moving the "Requirements language" text into > a section, > > possibly under Introduction. > > I'll need to review the draft to identify this text, but the > suggestion > sounds very reasonable. It's at the end of the Abstract before section 1. > > > section 2.1 > > "Specific attributes for use with SNMP Transport Models are > > recommended in this document." I don't think this document should be > > used to make recommendations of specific RADIUS attributes. This > > document should simply be about how to use the management-related > > attributes that are defined, in an SNMP environment. > > Huh? You want this document to describe how to use RADIUS for > authentication and authorization of SNMP access without > mentioning specific > RADIUS attributes? I know that SNMP documentation and > architecture is big > on abstraction, models, and such. RADIUS documentation > doesn't go in for > that sort of thing, for better or worse. I wouldn't know > where to begin... My objection is to the use of "recommended". This should be about how to map from these specific attributes to SNMP. We should not be "recommending" anything, just using them. Recommending is what you do when you're trying to sell something. "Specific attributes for use with management protocols are used in this document." is fine. It removes the "recommended". > > (but isn't the hint really part of an authorization request rather > > than an authentication request? > > You can't really separate the two in RADIUS, as much as one > might like to. > I know this has been an issue in the ISMS work, but RADIUS is a legacy > protocol and "it is what it is". I am not complaining about them being bundled together in RADIUS messages. They are two separate concepts, even if they are mixed together in RADIUS messages. authenticate is "to prove or serve to prove the authenticity of", such as an identity. Whereas authorization is "An approval that is granted to a system entity to access a system resource." RADIUS attributes used for proving a user's identity are about authentication. RADIUS attributes that are about the provisioning of the approved service are about authorization. It would help if you used the words correctly in text. > > section 2.2 eliminate the sentence > > " Specific attributes for use with SNMP Transport Models are > > recommended in this document." > > This gets back to my previous question. Are you effectively > asking the > authors to create an abstract "model" of how RADIUS might > interact with > SNMP? I don't think that's what we have been tasked to > produce. If that's > not what you're asking of us, what is your concern with specificity? I don't have concern with specificity; it is with "recommending". I would have less issue with " Specific attributes for use with SNMP Transport Models are used in this document." I do not however, believe that the attributes are for use with specific transport models, just with management protocols in general. "Specific attributes for use with management protocols are used in this document." is fine. It removes the "recommended". > > 1. Session-Timeout > > 2. Inactivity-Timeout." > > What transport model does this? > > Well, I'm not sure any of them do... more like they should. > I think this > needs some discussion. I'll let you start a thread on that topic. > > section 2.4. I think the authorization attributes provided by RADIUS > > should probably be captured as part of the LCD, as part of > > transport-specific information. > > I don't understand. I think the Management-Policy-ID, and the Transport-Protection attributes should be captured by an SNMP Transport Model, and stored in the SNMP LCD as part of the transport-specific information received. This will make it available for later use by access control models. > > > section 3 should be part of the introduction to RADIUS and the > > management related attributes. It seems out of place here. > > Well, in RADIUS documents there is always a Table of > Attributes near the end > of the document, just before such sections as the Security > Considerations. > In case it's not already apparent, the authors are following > RADIUS document > style and not SNMP document style. OK. This document is not about defining new attributes; it is about how SNMP should use specific attributes. I suggest making the isms document SNMP-like, and the radext document RADIUS-like. > > > Paragraph three discusses selecting SNMPv1 and SNMPv2c. I think the > > discussion of using RADIUS with these needs further discussion. > > OK. I'm sure I got this text from some posting on the ISMS > list, but I'm > not sure it's correct or complete. Yes, it's not the completeness or correcetness I have concerns with. There are some open issues in ISMS, and this paragraph may change as we resolve those open issues. We need to discuss this further. In addition, there are some other issues with SNMPv1/v2c that may come into play if the radext attributes do not support specifying a particular SNMP transport model or a specific transport protocol (which would permit us to assume which specific SNMP transport model is involved): > > > Currently, SNMPv1 can be used with an SSH tunnel, with no transport > > model to provide a binding; we might develop a transport > model with a > > binding. The RADIUS attributes for management, however, may > not allow > > us to choose which transport model or even which transport protocol, > > and under those conditions, I don't know what we have for security > > with an SNMPv1 or SNMPv2c (or SNMPv3) message, since we may have no > > transport model to provide a mapping between the transport layer > > credentials and the SNMP-specific securityModel/Name/Level. This also will require further discussion. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 2 07:12:34 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9E553A6B81; Wed, 2 Apr 2008 07:12:34 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87463A6A61 for ; Wed, 2 Apr 2008 07:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[AWL=1.826, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfBUIxL71ZcO for ; Wed, 2 Apr 2008 07:12:26 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id B6BB328C156 for ; Wed, 2 Apr 2008 07:11:42 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id 8as41Z0051GXsucA20Hb00; Wed, 02 Apr 2008 14:10:28 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id 8eBg1Z00C24Kx1C8T00000; Wed, 02 Apr 2008 14:11:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=s4SXJgON34-OsTvINqIA:9 a=5RzM_UAZfGEJhNFOPIsA:7 a=bRYbega2ok4h281sx-nwaQ6e5BEA:4 a=oltf0pfCdT4A:10 From: "David B. Nelson" To: References: <00d701c89389$9f805710$0600a8c0@china.huawei.com><001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2> <017101c89464$6d185210$0600a8c0@china.huawei.com> Date: Wed, 2 Apr 2008 10:11:45 -0400 Message-ID: <038f01c894cb$7cbc5b50$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <017101c89464$6d185210$0600a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciTiZ79SOFZmNc6RJWNJ4eQ2H0HlQAl2/IgAAW7hyAAI4RgQA== Subject: Re: [Isms] WGLC: draft-ietf-isms-radius-usage-02 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington Writes... > I am only suggesting that the design of the document should be that > it is specifically an SNMP mapping to these documents, as if there > were also CLI mapping documents and Netconf mappings documents, etc. OK. I understand. You want us to design the document following an SMNP-like architecture, with abstract subsystems and concrete models. Personally, I think that's asking a bit much, but we'll see what we can do. > My objection is to the use of "recommended". Hmmm. "RECOMMENDED" is an RFC 2119 keyword, synonymous with "SHOULD". From that RFC: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. > Recommending is what you do when you're trying to sell something. So, we should issue an errata against RFC 2119? :-) Seriously, though, it's in the "RECOMMENDED" sense that I used "recommended", but I think we can easily wordsmith the text you find confusing to fix that issue, perhaps just substituting "SHOULD". Consider it done. > I am not complaining about them being bundled together in RADIUS > messages. They are two separate concepts, even if they are mixed > together in RADIUS messages. Agreed. > RADIUS attributes used for proving a user's identity are about > authentication. RADIUS attributes that are about the provisioning > of the approved service are about authorization. Agreed. > It would help if you used the words correctly in text. I sometimes type one when I meant to type the other, so if you find such a typo please bring it to my attention. I fully understand the conceptual difference. > > > 1. Session-Timeout > > > 2. Inactivity-Timeout." > > > What transport model does this? > > > > Well, I'm not sure any of them do... more like they should. > > I think this needs some discussion. > > I'll let you start a thread on that topic. Since others have weighed in on this, I will start another thread. > I think the Management-Policy-ID, and the Transport-Protection > attributes should be captured by an SNMP Transport Model, and stored > in the SNMP LCD as part of the transport-specific information > received. This will make it available for later use by access control > models. Is this an "Implementation Note"? Is it your intent that this document places this requirement on the SNMP engine implementation? > I suggest making the isms document SNMP-like, and the radext document > RADIUS-like. Sounds nice, but I'm not sure I'm up to the task. :-( > Yes, it's not the completeness or correcetness I have concerns with. > There are some open issues in ISMS, and this paragraph may change as > we resolve those open issues. We need to discuss this further. OK. Are you suggesting that the RADIUS Usage document cannot be competed until the remaining issues in the other ISMS documents are resolved? > In addition, there are some other issues with SNMPv1/v2c that may come > into play if the radext attributes do not support specifying a > particular SNMP transport model or a specific transport protocol > (which would permit us to assume which specific SNMP transport model > is involved): > > > > Currently, SNMPv1 can be used with an SSH tunnel, with no > > > transport model to provide a binding; we might develop a transport > > > model with a binding. The RADIUS attributes for management, however, > > > may not allow us to choose which transport model or even which > > > transport protocol, and under those conditions, I don't know what > > > we have for security with an SNMPv1 or SNMPv2c (or SNMPv3) message, > > > since we may have no transport model to provide a mapping between > > > the transport layer credentials and the SNMP-specific > > > securityModel/Name/Level. > > This also will require further discussion. OK. Let's start a discussion of that. I don't think that having the RADIUS Server, and the system administrator, specify particular transport protocols and granular security parameters of such protocols is ultimately useful. It is certainly possible to define RADIUS attributes to do that, even if it turns out there are a large number of them and it takes us quite a while to define them correctly. My concern is that it will be hard for an administrator to apply them correctly. Of course, RADIUS Server implementations could be created with wizards and other UI features to assist in creating correct configurations. I'm just not sure that's where we want or need to go. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 2 07:54:21 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F1328C518; Wed, 2 Apr 2008 07:54:21 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E33E28C564 for ; Wed, 2 Apr 2008 07:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uO9DiV-ugvtE for ; Wed, 2 Apr 2008 07:54:19 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id A315328C4F7 for ; Wed, 2 Apr 2008 07:54:19 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m32Es7Uo009625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 10:54:08 -0400 (EDT) Date: Wed, 02 Apr 2008 10:54:07 -0400 From: Jeffrey Hutzelman To: David Harrington , "'David B. Nelson'" , isms@ietf.org Message-ID: In-Reply-To: <017101c89464$6d185210$0600a8c0@china.huawei.com> References: <00d701c89389$9f805710$0600a8c0@china.huawei.com> <001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2> <017101c89464$6d185210$0600a8c0@china.huawei.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] WGLC: draft-ietf-isms-radius-usage-02 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Tuesday, April 01, 2008 09:54:02 PM -0400 David Harrington wrote: > My objection is to the use of "recommended". > This should be about how to map from these specific attributes to > SNMP. > We should not be "recommending" anything, just using them. > Recommending is what you do when you're trying to sell something. Wow. That is completely not what I thought you were trying to say. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 2 07:58:34 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 172AF3A6EEB; Wed, 2 Apr 2008 07:58:34 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168C23A6F25 for ; Wed, 2 Apr 2008 07:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5FRnmY5GxHf for ; Wed, 2 Apr 2008 07:58:30 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 00A713A6F12 for ; Wed, 2 Apr 2008 07:58:29 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA09.westchester.pa.mail.comcast.net with comcast id 8aD01Z0040Fqzac590Kx00; Wed, 02 Apr 2008 14:56:51 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id 8eyQ1Z0094HwxpC3U00000; Wed, 02 Apr 2008 14:58:30 +0000 X-Authority-Analysis: v=1.0 c=1 a=WbFsHuEpKaCAqjB5TgEA:9 a=H83Nfs3h5FLJbp9RlDerJlKDE0AA:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'David B. Nelson'" , References: <00d701c89389$9f805710$0600a8c0@china.huawei.com> <001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2> <017101c89464$6d185210$0600a8c0@china.huawei.com> Date: Wed, 2 Apr 2008 10:58:24 -0400 Message-ID: <01d501c894d2$005850d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: thread-index: AciU0WyI3MdkPlNsSZONpORPm3erswAAH/Tw Subject: Re: [Isms] WGLC: draft-ietf-isms-radius-usage-02 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I have a bad cold this week, and apparently my review was hard for multiple people to understad my intentions. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Wednesday, April 02, 2008 10:54 AM > To: David Harrington; 'David B. Nelson'; isms@ietf.org > Cc: jhutz@cmu.edu > Subject: Re: [Isms] WGLC: draft-ietf-isms-radius-usage-02 > > --On Tuesday, April 01, 2008 09:54:02 PM -0400 David Harrington > wrote: > > > My objection is to the use of "recommended". > > This should be about how to map from these specific attributes to > > SNMP. > > We should not be "recommending" anything, just using them. > > Recommending is what you do when you're trying to sell something. > > Wow. That is completely not what I thought you were trying to say. > > -- Jeff > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 2 09:37:45 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4D13A6DEB; Wed, 2 Apr 2008 09:37:45 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAE7B28C302 for ; Wed, 2 Apr 2008 09:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDINBixq7o46 for ; Wed, 2 Apr 2008 09:37:43 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 276743A6D35 for ; Wed, 2 Apr 2008 09:37:43 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA06.westchester.pa.mail.comcast.net with comcast id 8g7D1Z0030mv7h05602h00; Wed, 02 Apr 2008 16:36:32 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.westchester.pa.mail.comcast.net with comcast id 8gdg1Z00A4HwxpC3X00000; Wed, 02 Apr 2008 16:37:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=CY2jlEA_dXQYsZKNFocA:9 a=fXPSpPuIDDe8gpvPkiJrMAnueooA:4 a=si9q_4b84H0A:10 a=lZB815dzVvQA:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'David B. Nelson'" , References: <00d701c89389$9f805710$0600a8c0@china.huawei.com><001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2> <017101c89464$6d185210$0600a8c0@china.huawei.com> <038f01c894cb$7cbc5b50$6401a8c0@NEWTON603> Date: Wed, 2 Apr 2008 12:37:39 -0400 Message-ID: <020401c894df$ddb391d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <038f01c894cb$7cbc5b50$6401a8c0@NEWTON603> thread-index: AciTiZ79SOFZmNc6RJWNJ4eQ2H0HlQAl2/IgAAW7hyAAI4RgQAADAIBQ Subject: Re: [Isms] WGLC: draft-ietf-isms-radius-usage-02 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, comments inline. > -----Original Message----- > From: David B. Nelson [mailto:d.b.nelson@comcast.net] > Sent: Wednesday, April 02, 2008 10:12 AM > To: isms@ietf.org > Cc: 'David Harrington' > Subject: RE: [Isms] WGLC: draft-ietf-isms-radius-usage-02 > > David Harrington Writes... > > > I am only suggesting that the design of the document should be that > > it is specifically an SNMP mapping to these documents, as if there > > were also CLI mapping documents and Netconf mappings documents, etc. > > OK. I understand. You want us to design the document > following an SMNP-like > architecture, with abstract subsystems and concrete models. > Personally, I > think that's asking a bit much, but we'll see what we can do. No. I am not suggesting any sort of architectural design with abstract subsystems or anything else. I find the document hard to read for a number of reasons. One of the biggest is that, at times, it feels like a promotional brochure for your attributes, rather than a technical discussion of how to utilize those attributes in an SNMP environment. That was my point about writing from the viewpoint that they have already been approved for use; stop trying to sell them to us; tell us how to apply them. > > > My objection is to the use of "recommended". > > Hmmm. "RECOMMENDED" is an RFC 2119 keyword, synonymous with > "SHOULD". From > that RFC: > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > > > Recommending is what you do when you're trying to sell something. > > So, we should issue an errata against RFC 2119? :-) If you are using recommended as an RFC2119 keyword, please capitalize it so it is clear that is the way you intended it to be interpreted. > > Seriously, though, it's in the "RECOMMENDED" sense that I used > "recommended", but I think we can easily wordsmith the text you find > confusing to fix that issue, perhaps just substituting > "SHOULD". Consider > it done. good. I am not certain that this document should be saying SHOULD for attributes defined in a different document however. If they do not use the management attributes, then this document would make little sense. I will wait until I see how you reformulate this. > > I think the Management-Policy-ID, and the Transport-Protection > > attributes should be captured by an SNMP Transport Model, and stored > > in the SNMP LCD as part of the transport-specific information > > received. This will make it available for later use by > access control > > models. > > Is this an "Implementation Note"? Is it your intent that > this document > places this requirement on the SNMP engine implementation? We have a problem in ISMS. We are expected to folow the RFC3411 architecture modularity, yet we need to pass provisioning information acquired during the RADIUS authentication and service authorization phase to the access control phase. The ASIs do not support this. If we do not capture this informaton in a predictable manner, then no ACM will know where to find this information. Unfortunately, we don't define any way to pass this information, and we don't concretely define what is in the LCD, so we cannot be very clear about how this information gets captured and made available to ACMs. The closest we come is to say that the LCD contains information recorded by the transport model received from the transport layer. So I suggest we provide an implementation note that says "you can record this provisioning information in the LCD, in an implementation-specific manner", and then later, when we write an ACM to utilize RADIUS info, we can say something like "the ACM checks to see if there is provisioning information in the LCD related to this securityName" or some such hand-waving. > > > I suggest making the isms document SNMP-like, and the > radext document > > RADIUS-like. > > Sounds nice, but I'm not sure I'm up to the task. :-( I'll help by pointing out things I find "unusual" in a document. > > > Yes, it's not the completeness or correcetness I have concerns with. > > There are some open issues in ISMS, and this paragraph may change as > > we resolve those open issues. We need to discuss this further. > > OK. Are you suggesting that the RADIUS Usage document cannot > be competed > until the remaining issues in the other ISMS documents are resolved? Yes. > > > In addition, there are some other issues with SNMPv1/v2c > that may come > > into play if the radext attributes do not support specifying a > > particular SNMP transport model or a specific transport protocol > > (which would permit us to assume which specific SNMP transport model > > is involved): > > > > > > Currently, SNMPv1 can be used with an SSH tunnel, with no > > > > transport model to provide a binding; we might develop > a transport > > > > model with a binding. The RADIUS attributes for > management, however, > > > > may not allow us to choose which transport model or even which > > > > transport protocol, and under those conditions, I don't > know what > > > > we have for security with an SNMPv1 or SNMPv2c (or > SNMPv3) message, > > > > since we may have no transport model to provide a > mapping between > > > > the transport layer credentials and the SNMP-specific > > > > securityModel/Name/Level. > > > > This also will require further discussion. > > OK. Let's start a discussion of that. I don't think that > having the RADIUS > Server, and the system administrator, specify particular > transport protocols > and granular security parameters of such protocols is > ultimately useful. It > is certainly possible to define RADIUS attributes to do that, > even if it > turns out there are a large number of them and it takes us > quite a while to > define them correctly. My concern is that it will be hard for an > administrator to apply them correctly. Of course, RADIUS Server > implementations could be created with wizards and other UI features to > assist in creating correct configurations. I'm just not sure > that's where > we want or need to go. > Back around 1995, there was a suggestion to "just use IPsec". That wasn't possible because IPSec has no "northbound" interface to pass information to the upper layers, such as which identity was authenticated, and which type of IPsec was used. Around 2001, Jeff Schiller started giving Sunday tutorials on why it is was unacceptable to say "just use IPsec" or "just use" other lower layer protocols; it is important to specify how you will actually communicate between the lower layer and the application. I am concerned that dropping the choice of transport protocol really limits how we can communicate with the lower layer to get information we need to determine what level of access control should be applied. "any protocol that provides transport layer encryption" may not be good enough for operators. But we can discuss this further on the list. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 2 09:59:52 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96133A6F12; Wed, 2 Apr 2008 09:59:52 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD74C28C25D for ; Wed, 2 Apr 2008 09:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[AWL=1.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilgkQFvVaqba for ; Wed, 2 Apr 2008 09:59:50 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id 9F46B3A6F12 for ; Wed, 2 Apr 2008 09:59:50 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id 8gyh1Z00F0b6N64A100000; Wed, 02 Apr 2008 16:58:41 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id 8gzn1Z00224Kx1C8P00000; Wed, 02 Apr 2008 16:59:49 +0000 X-Authority-Analysis: v=1.0 c=1 a=4FKt1pMKxlOYgxN4qKkA:9 a=rq6_cAPNgfzZNvDz_lY7-z_w3lMA:4 a=oltf0pfCdT4A:10 From: "David B. Nelson" To: References: <00d701c89389$9f805710$0600a8c0@china.huawei.com><001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2> <017101c89464$6d185210$0600a8c0@china.huawei.com> <038f01c894cb$7cbc5b50$6401a8c0@NEWTON603> <020401c894df$ddb391d0$0600a8c0@china.huawei.com> Date: Wed, 2 Apr 2008 12:59:52 -0400 Message-ID: <03c601c894e2$f8c21d90$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <020401c894df$ddb391d0$0600a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciTiZ79SOFZmNc6RJWNJ4eQ2H0HlQAl2/IgAAW7hyAAI4RgQAADAIBQAAOf2bA= Subject: Re: [Isms] WGLC: draft-ietf-isms-radius-usage-02 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington writes... > I find the document hard to read for a number of reasons. > One of the biggest is that, at times, it feels like a promotional > brochure for your attributes, rather than a technical discussion of > how to utilize those attributes in an SNMP environment. OK. That's something concrete we can work on. Thanks. > If you are using recommended as an RFC2119 keyword, please capitalize > it so it is clear that is the way you intended it to be interpreted. OK. > I am not certain that this document should be saying SHOULD for > attributes defined in a different document however. If they do not use > the management attributes, then this document would make little sense. > I will wait until I see how you reformulate this. I see this document as an analog to RFC 3580, which explains how RADIUS attributes are to be used, applied and interpreted in provisioning network access using IEEE 802.1X port-based authentication. The [short] title "RADIUS Usage for SNMP Transport Models" was chosen to mimic "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines". Perhaps if the authors are successful in emulating the layout and style of RFC 3580 we will have succeeded in creating a more readable document. > We have a problem in ISMS. We are expected to folow the RFC3411 > architecture modularity, yet we need to pass provisioning information > acquired during the RADIUS authentication and service authorization > phase to the access control phase. The ASIs do not support this. If we > do not capture this informaton in a predictable manner, then no ACM > will know where to find this information. Right. > Unfortunately, we don't define any way to pass this information, and > we don't concretely define what is in the LCD, so we cannot be very > clear about how this information gets captured and made available to > ACMs. The closest we come is to say that the LCD contains information > recorded by the transport model received from the transport layer. > > So I suggest we provide an implementation note that says "you can > record this provisioning information in the LCD, in an > implementation-specific manner", and then later, when we write an ACM > to utilize RADIUS info, we can say something like "the ACM checks to > see if there is provisioning information in the LCD related to this > securityName" or some such hand-waving. OK. I'll add some text to that effect in the next version. If you have some particular text you'd prefer to see, by all means send it along. > > Are you suggesting that the RADIUS Usage document cannot > > be completed until the remaining issues in the other ISMS documents > > are resolved? > > Yes. OK. Then, I guess we need some discussion of that list of open issues you recently posted to the list. Folks, can we start that discussion, please? > Back around 1995, there was a suggestion to "just use IPsec". > That wasn't possible because IPSec has no "northbound" interface to > pass information to the upper layers, such as which identity was > authenticated, and which type of IPsec was used. Yes, a significant disappointment, IMHO. But I digress. > Around 2001, Jeff Schiller started giving Sunday tutorials on why it > is was unacceptable to say "just use IPsec" or "just use" other lower > layer protocols; it is important to specify how you will actually > communicate between the lower layer and the application. Right. > I am concerned that dropping the choice of transport protocol really > limits how we can communicate with the lower layer to get information > we need to determine what level of access control should be applied. > "any protocol that provides transport layer encryption" may not be > good enough for operators. I wonder... > But we can discuss this further on the list. Yeah, let's start a separate thread on this issue. I do have some thoughts and questions on this to share. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 2 10:11:52 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 837713A6EB6; Wed, 2 Apr 2008 10:11:52 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC713A67EB for ; Wed, 2 Apr 2008 10:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[AWL=0.959, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMVM2Atn46hg for ; Wed, 2 Apr 2008 10:11:45 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id BA3E93A68A3 for ; Wed, 2 Apr 2008 10:11:44 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id 8h0Y1Z0010lTkoCA801T00; Wed, 02 Apr 2008 17:10:40 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id 8hBk1Z00624Kx1C8Q00000; Wed, 02 Apr 2008 17:11:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=S14oas1Z_mlJIvh_LvEA:9 a=nBJoEAYzQV7c2MINWA52jZ598H0A:4 a=CWfAmLVWKswA:10 From: "David B. Nelson" To: Date: Wed, 2 Apr 2008 13:11:49 -0400 Message-ID: <03c701c894e4$a44811a0$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciU5KM/xj++6LE+TGKccOUhIuAYMQ== Subject: [Isms] Session timeouts? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I'm starting a separate thread to discuss the issue of providing RADIUS-provisioned session timeouts for SNMP connections. This came up in the review comments on the RADIUS Usage for SNMP draft. > > 1. Session-Timeout > > 2. Inactivity-Timeout. > > What transport model does this? > > Well, I'm not sure any of them do... more like they should. > I think this needs some discussion. A couple of folks opined that this is useful. RADIUS has a long history of provisioning session timeouts for the services that it authorizes, dating back to its original use in terminal servers and dial-up remote access servers. For example, the RADIUS usage guide for 802.1X (RFC 3580) describes how the RADIUS attributes Session-Timeout (27) and Idle-Timeout (28) affects network connections moderated by an 802.1X Controlled Port. I think the RADIUS usage guide for SNMP should do likewise. The issue in question seems to be where this happens, and the only reasonable answer seems to be in the secure transport (e.g. SSH). ISMS cannot place requirements on SSH usage of RADIUS generally, but we can probably place requirements on SSH usage of RADIUS when SSH is used to support an SNMP Transport Model. Does that seem reasonable? _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 2 10:25:51 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA2FC3A6F11; Wed, 2 Apr 2008 10:25:51 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558303A6D66 for ; Wed, 2 Apr 2008 10:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.708, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoISoLR06c+R for ; Wed, 2 Apr 2008 10:25:49 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id DF2F73A6F12 for ; Wed, 2 Apr 2008 10:25:15 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA06.westchester.pa.mail.comcast.net with comcast id 8hBm1Z00116LCl05600z00; Wed, 02 Apr 2008 17:24:05 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.westchester.pa.mail.comcast.net with comcast id 8hRD1Z0044HwxpC3S00000; Wed, 02 Apr 2008 17:25:17 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=EBuCNr_PfH1pZo8e9OgA:9 a=9tg4oerk-0EdQGxMQ7EA:7 a=OfLfcKnfLAmKdzIXIxOMeIr2KkMA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <03c701c894e4$a44811a0$6401a8c0@NEWTON603> Date: Wed, 2 Apr 2008 13:25:13 -0400 Message-ID: <020701c894e6$82a4b380$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <03c701c894e4$a44811a0$6401a8c0@NEWTON603> thread-index: AciU5KM/xj++6LE+TGKccOUhIuAYMQAANbCQ Subject: Re: [Isms] Session timeouts? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, Since we don't know which implementation of SSH or which implementation of RADIUS will be used, would it make sense to simply add an implementer note that they might want to configure their implementation to utilize such parameters? Are there some values we should recommend as being appropriate to enhance interoperability? Or would this even affect interoperability? Our SSH transport model is designed to handle finding that no session is currently open (so it opens one), or that a session might have terminated between the time of receiving a request and sending the response (so it discards the response). Is this actually germane to the SNMP mapping? Would this be better discussed in the radext draft for mgmt attributes? dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of David B. Nelson > Sent: Wednesday, April 02, 2008 1:12 PM > To: isms@ietf.org > Subject: [Isms] Session timeouts? > > I'm starting a separate thread to discuss the issue of providing > RADIUS-provisioned session timeouts for SNMP connections. > This came up in > the review comments on the RADIUS Usage for SNMP draft. > > > > 1. Session-Timeout > > > 2. Inactivity-Timeout. > > > What transport model does this? > > > > Well, I'm not sure any of them do... more like they should. > > I think this needs some discussion. > > A couple of folks opined that this is useful. RADIUS has a > long history of > provisioning session timeouts for the services that it > authorizes, dating > back to its original use in terminal servers and dial-up remote access > servers. For example, the RADIUS usage guide for 802.1X (RFC 3580) > describes how the RADIUS attributes Session-Timeout (27) and > Idle-Timeout > (28) affects network connections moderated by an 802.1X > Controlled Port. I > think the RADIUS usage guide for SNMP should do likewise. > > The issue in question seems to be where this happens, and the only > reasonable answer seems to be in the secure transport (e.g. > SSH). ISMS > cannot place requirements on SSH usage of RADIUS generally, but we can > probably place requirements on SSH usage of RADIUS when SSH is used to > support an SNMP Transport Model. > > Does that seem reasonable? > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 2 10:46:05 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2D128C173; Wed, 2 Apr 2008 10:46:05 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF7528C17D for ; Wed, 2 Apr 2008 10:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BU0Dd5bsP+jK for ; Wed, 2 Apr 2008 10:46:02 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 3ED4A28C59E for ; Wed, 2 Apr 2008 10:45:38 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id 8h0P1Z0081HpZEsA204300; Wed, 02 Apr 2008 17:44:24 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id 8hlZ1Z00Q24Kx1C8a00000; Wed, 02 Apr 2008 17:45:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=NgleuxDeCDi8gv6CNWoA:9 a=BMeUxjrYvDsM-rrLQk0A:7 a=M62B7JVYtcTKxmnCa0gjwuJQhjQA:4 a=MxZ3bB5I4kYA:10 From: "David B. Nelson" To: References: <03c701c894e4$a44811a0$6401a8c0@NEWTON603> <020701c894e6$82a4b380$0600a8c0@china.huawei.com> Date: Wed, 2 Apr 2008 13:45:38 -0400 Message-ID: <03dd01c894e9$5de70090$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <020701c894e6$82a4b380$0600a8c0@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciU5KM/xj++6LE+TGKccOUhIuAYMQAANbCQAACRkhA= Subject: Re: [Isms] Session timeouts? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > Since we don't know which implementation of SSH or which > implementation of RADIUS will be used, would it make sense to simply > add an implementer note that they might want to configure their > implementation to utilize such parameters? That presumes that it's a configuration option, i.e. that the feature has been coded into the implementation and simply needs to be enabled at run time. That may not always be the case. > Are there some values we should recommend as being appropriate to > enhance interoperability? Or would this even affect interoperability? I think all we need to specify is that an SNMP session is closed by the SSH server after Session-Timeout seconds, or after Idle-Timeout seconds elapse between SNMP messages. That is to say, that the SSH server takes notice of the session limiting authorization information. > Our SSH transport model is designed to handle finding that no session > is currently open (so it opens one), or that a session might have > terminated between the time of receiving a request and sending the > response (so it discards the response). Right. > Is this actually germane to the SNMP mapping? Would this be better > discussed in the radext draft for mgmt attributes? Well, the RADEXT draft defines _new_ RADIUS attributes for management authorization. It does not indicate how those attributes are used in a specific application (e.g. SNMP, NETCONF, et. al.), although it does describe how they are generally used in an application agnostic fashion. It does not layer additional usage guidelines _existing_ attributes, for specific applications. I think it is preferable to define attributes in one place (e.g. the base document RFC 2865 or the Management Authorization draft) and explain how they are applied in a particular application in a separate draft (like RFC 3580 does for 802.1X). _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 2 12:34:34 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9025B3A68D4; Wed, 2 Apr 2008 12:34:34 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8916A3A6B0A for ; Wed, 2 Apr 2008 12:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEoZdiJIGiNT for ; Wed, 2 Apr 2008 12:34:32 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 6446F3A68D4 for ; Wed, 2 Apr 2008 12:34:32 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m32JYN2G027942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 15:34:23 -0400 (EDT) Date: Wed, 02 Apr 2008 15:34:23 -0400 From: Jeffrey Hutzelman To: "David B. Nelson" , isms@ietf.org Message-ID: In-Reply-To: <03dd01c894e9$5de70090$6401a8c0@NEWTON603> References: <03c701c894e4$a44811a0$6401a8c0@NEWTON603> <020701c894e6$82a4b380$0600a8c0@china.huawei.com> <03dd01c894e9$5de70090$6401a8c0@NEWTON603> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] Session timeouts? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Wednesday, April 02, 2008 01:45:38 PM -0400 "David B. Nelson" wrote: >> Since we don't know which implementation of SSH or which >> implementation of RADIUS will be used, would it make sense to simply >> add an implementer note that they might want to configure their >> implementation to utilize such parameters? > > That presumes that it's a configuration option, i.e. that the feature has > been coded into the implementation and simply needs to be enabled at run > time. That may not always be the case. True, but that is a problem for the ssh implementors. I think it's entirely reasonable to specify RADIUS attributes which describe session timeout behavior for SSH, with the understanding that while there is a standard way to describe the timeouts, there is no requirement that an SSH server actually implement them. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 2 12:55:58 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78BAC3A6F55; Wed, 2 Apr 2008 12:55:58 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9673528C5C9 for ; Wed, 2 Apr 2008 12:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGL9+GAOmutt for ; Wed, 2 Apr 2008 12:55:55 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id EAF5E28C619 for ; Wed, 2 Apr 2008 12:55:11 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id 8gzG1Z0050FhH24A50Jt00; Wed, 02 Apr 2008 19:53:21 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id 8jvA1Z00224Kx1C8U00000; Wed, 02 Apr 2008 19:55:11 +0000 X-Authority-Analysis: v=1.0 c=1 a=wr8r9haDnik9wnZEOZcA:9 a=34LotB2yURCQH3gENUxYO3SGwuwA:4 a=QMgMR9M9BAsA:10 From: "David B. Nelson" To: References: <03c701c894e4$a44811a0$6401a8c0@NEWTON603> <020701c894e6$82a4b380$0600a8c0@china.huawei.com> <03dd01c894e9$5de70090$6401a8c0@NEWTON603> Date: Wed, 2 Apr 2008 15:55:15 -0400 Message-ID: <043c01c894fb$792db580$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciU+JOmjd3sZivITVyb0kQ7AXceOQAAOZyA Cc: 'Jeffrey Hutzelman' Subject: Re: [Isms] Session timeouts? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Jeffrey Hutzelman writes... > I think it's entirely reasonable to specify RADIUS attributes which > describe session timeout behavior for SSH, with the understanding that > while there is a standard way to describe the timeouts, there is no > requirement that an SSH server actually implement them. Right. RADIUS standards do not create requirements for applications to implement the use of certain attributes, or support certain features; only end users do that. The most that the RADIUS documents dictate is how the attributes are to be used, if the feature is implemented. I think it's useful to point out what RADIUS features are available for use with SNMP Transport Models. That's how I would propose to handle the session timeout issue for ISMS, to describe how RADIUS attributes are used to provision this feature, and suggest (dare I say recommend?) how it might be implemented, e.g. in the SSH server. If it turns out that there are Security Considerations surrounding the decision to implement session timeouts (or not) we could describe them. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 2 15:15:34 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F5B3A6961; Wed, 2 Apr 2008 15:15:34 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3452528C118 for ; Wed, 2 Apr 2008 15:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-CaBu8SkXuh for ; Wed, 2 Apr 2008 15:15:32 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4926028C1D8 for ; Wed, 2 Apr 2008 15:15:27 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2008 15:15:29 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m32MFSaf019886; Wed, 2 Apr 2008 15:15:28 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m32MFSsa012759; Wed, 2 Apr 2008 22:15:28 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Apr 2008 15:15:28 -0700 Received: from 171.69.75.173 ([171.69.75.173]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Apr 2008 22:15:28 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 02 Apr 2008 15:15:27 -0700 From: Kaushik Narayan To: David Harrington , Message-ID: Thread-Topic: [Isms] Session timeouts? Thread-Index: AciU5KM/xj++6LE+TGKccOUhIuAYMQAANbCQAApk+J4= In-Reply-To: <020701c894e6$82a4b380$0600a8c0@china.huawei.com> Mime-version: 1.0 X-OriginalArrivalTime: 02 Apr 2008 22:15:28.0761 (UTC) FILETIME=[0EEE5E90:01C8950F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3109; t=1207174529; x=1208038529; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20Kaushik=20Narayan=20 |Subject:=20Re=3A=20[Isms]=20Session=20timeouts? |Sender:=20; bh=3HpONdatBk14zJyrbDhApWeJHCpeDIXjGQCGGLUKTLI=; b=QGKFDJKy3P09YDkbmP2PTMPwvmHpBEb3lQi4TKcT8lpJppIGSFXP/P+yOb zbOLubwbqcVzgRFuNELnbCw51tEQpd1IBieho6UeG7hpZAeNMimO4LMQXza0 y882su5XXX; Authentication-Results: sj-dkim-4; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Isms] Session timeouts? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi David, I think it is useful to specify that the timeout attributes be included in the RADIUS response but agree that it would be up to implementations to act on these attributes. This does not effect the SNMP mapping but creates requirements for transport implementations that may be used to support ISMS. Regards, kaushik On 4/2/08 10:25 AM, "David Harrington" wrote: > Hi, > > Since we don't know which implementation of SSH or which > implementation of RADIUS will be used, would it make sense to simply > add an implementer note that they might want to configure their > implementation to utilize such parameters? > > Are there some values we should recommend as being appropriate to > enhance interoperability? Or would this even affect interoperability? > Our SSH transport model is designed to handle finding that no session > is currently open (so it opens one), or that a session might have > terminated between the time of receiving a request and sending the > response (so it discards the response). > > Is this actually germane to the SNMP mapping? Would this be better > discussed in the radext draft for mgmt attributes? > > dbh > >> -----Original Message----- >> From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On >> Behalf Of David B. Nelson >> Sent: Wednesday, April 02, 2008 1:12 PM >> To: isms@ietf.org >> Subject: [Isms] Session timeouts? >> >> I'm starting a separate thread to discuss the issue of providing >> RADIUS-provisioned session timeouts for SNMP connections. >> This came up in >> the review comments on the RADIUS Usage for SNMP draft. >> >>>> 1. Session-Timeout >>>> 2. Inactivity-Timeout. >>>> What transport model does this? >>> >>> Well, I'm not sure any of them do... more like they should. >>> I think this needs some discussion. >> >> A couple of folks opined that this is useful. RADIUS has a >> long history of >> provisioning session timeouts for the services that it >> authorizes, dating >> back to its original use in terminal servers and dial-up remote > access >> servers. For example, the RADIUS usage guide for 802.1X (RFC 3580) >> describes how the RADIUS attributes Session-Timeout (27) and >> Idle-Timeout >> (28) affects network connections moderated by an 802.1X >> Controlled Port. I >> think the RADIUS usage guide for SNMP should do likewise. >> >> The issue in question seems to be where this happens, and the only >> reasonable answer seems to be in the secure transport (e.g. >> SSH). ISMS >> cannot place requirements on SSH usage of RADIUS generally, but we > can >> probably place requirements on SSH usage of RADIUS when SSH is used > to >> support an SNMP Transport Model. >> >> Does that seem reasonable? >> >> >> _______________________________________________ >> Isms mailing list >> Isms@ietf.org >> https://www.ietf.org/mailman/listinfo/isms >> > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Apr 3 07:54:03 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9858E28C6D9; Thu, 3 Apr 2008 07:54:03 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5010928C6D8 for ; Thu, 3 Apr 2008 07:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLBlb-XRdSMU for ; Thu, 3 Apr 2008 07:53:58 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 40FD028C6E6 for ; Thu, 3 Apr 2008 07:53:57 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 970A7399BD8; Thu, 3 Apr 2008 07:52:13 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=/Zz6SJ0aCC9hQ+J5kzj1X07mGsM=; b=BWAk2HCCwNhJawuu/NObi277FXME4FHfbyqqblNGnuuMTl/ysDfYHA7+yRVAAA0B1WySGho1yBFDWaRHQzqATgKbQOJPt94YVVtN87tPGkCtW5BANqhMdAjrhkL7XmHtCXYj2GGvbsOQP7jb71kvOfMebGZVBz5GvwEpV5VxkyE= Received: by wes.hardakers.net (Postfix, from userid 274) id 5C6DC399C50; Thu, 3 Apr 2008 07:52:13 -0700 (PDT) From: Wes Hardaker To: "David B. Nelson" Organization: Sparta References: <03c701c894e4$a44811a0$6401a8c0@NEWTON603> <020701c894e6$82a4b380$0600a8c0@china.huawei.com> <03dd01c894e9$5de70090$6401a8c0@NEWTON603> <043c01c894fb$792db580$6401a8c0@NEWTON603> Date: Thu, 03 Apr 2008 07:52:13 -0700 In-Reply-To: <043c01c894fb$792db580$6401a8c0@NEWTON603> (David B. Nelson's message of "Wed, 2 Apr 2008 15:55:15 -0400") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.20 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [Isms] Session timeouts? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> "DBN" == David B Nelson writes: DBN> I think it's useful to point out what RADIUS features are available for use DBN> with SNMP Transport Models. How about an appendix of potentially beneficial RADIUS attributes that implementations may wish to consider using and what they mean if they do use them? One reason I say "appendix" is that as RADIUS changes over time I'm sure that the new parameters potentially added in the future won't discuss it's context within every mechanism that might be using RADIUS (like the ISMS transport). So it seems to me to be more "advice", which sounds more like (highly-useful) appendix material. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Apr 3 15:31:25 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2584928C65B; Thu, 3 Apr 2008 15:31:25 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239A028C614 for ; Thu, 3 Apr 2008 15:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.671, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwnB-90qLheN for ; Thu, 3 Apr 2008 15:31:23 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 09CBF28C191 for ; Thu, 3 Apr 2008 15:30:00 -0700 (PDT) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA09.westchester.pa.mail.comcast.net with comcast id 97nm1Z0030cZkys590KB00; Thu, 03 Apr 2008 22:28:23 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.westchester.pa.mail.comcast.net with comcast id 9AW11Z0044HwxpC3W00000; Thu, 03 Apr 2008 22:30:04 +0000 X-Authority-Analysis: v=1.0 c=1 a=mWReTE8q-DUA:10 a=8zEC761qZMh_xMwN5iEA:9 a=DstDPio5iszqAHqHX7QA:7 a=gET6CSVgliP6olb9zEvTHUKz7lUA:4 a=-utQw5L2n1AA:10 a=lZB815dzVvQA:10 a=5WZzfXpOq_gA:10 From: "David Harrington" To: "'David B. Nelson'" , References: <00d701c89389$9f805710$0600a8c0@china.huawei.com><001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2><017101c89464$6d185210$0600a8c0@china.huawei.com><038f01c894cb$7cbc5b50$6401a8c0@NEWTON603> <020401c894df$ddb391d0$0600a8c0@china.huawei.com> <00b001c895d6$62a32c60$1f0a0a0a@xpsuperdvd2> Date: Thu, 3 Apr 2008 18:30:01 -0400 Message-ID: <031001c895da$418f5220$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <00b001c895d6$62a32c60$1f0a0a0a@xpsuperdvd2> thread-index: AciTiZ79SOFZmNc6RJWNJ4eQ2H0HlQAl2/IgAAW7hyAAI4RgQAADAIBQAEBgE2AAAUoFIA== Subject: Re: [Isms] What granularity of attributes do we need for the secure transport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org In thinking about this, SNMP needs to know what "model" is used to authentication, and it know sthat RADIUS is the "model". I think SNMP actually doesn't need to know how the encryption is done, only that it is done. The operator can configure the underlying SSH or other transport to use the approrpiate authentication and encryption parameters. So this may actually be a non-issue. Do others agree? dbh > -----Original Message----- > From: David B. Nelson [mailto:dnelson@elbrysnetworks.com] > Sent: Thursday, April 03, 2008 6:02 PM > To: isms@ietf.org > Cc: 'David Harrington' > Subject: What granularity of attributes do we need for the > secure transport? > > David Harrington writes... > > > I am concerned that dropping the choice of transport protocol really > > limits how we can communicate with the lower layer to get > information > > we need to determine what level of access control should be applied. > > "any protocol that provides transport layer encryption" may not be > > good enough for operators. > > We need to have a further discussion of this issue on the > list, and I have > the action item start a thread to discuss it. > > Let's start that discussion now. > > I have a couple of thoughts to start off: > > -- If it turns out that we need something more granular than > Management-Transport-Protection = {No-Protection | > Integrity-Protection | > Integrity-Confidentiality-Protection} to address the specific > needs of SNMP, > could we at that point in time extend the list of enumerated > values for the > Management-Transport-Protection to include special cases for > SNMP? That > would eliminate the need to restore the Management-Transport-Protocol > attribute which caused a number of difficulties in terms of management > transports other than those used for SNMP. Once you specify > the protocol, > then you logically need to specify all sorts of other > protocol and security > related parameters. I think we don't want to go down that path. > > -- Why do we think that RADIUS authorization should be used > to provision > specific secure transport properties, such as protocol, cipher suite, > authentication mechanism, certificate chains, etc? It seems > to me that > these choices, while important to get right, do not need to > be conveyed on > each and every user access to the managed entity. They would > typically be > configured and left static for long periods of time. Yes, it > is required > that both ends of any such connection agree on the > parameters, but it seems > RADIUS authorization is not the optimal way to ensure that. > I think that > the choice that needs to be made on an access by access basis > is simply > whether or not the access needs to be secure. > > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Apr 3 16:06:37 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174CC28C32B; Thu, 3 Apr 2008 16:06:37 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2397B3A6CFB for ; Thu, 3 Apr 2008 16:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.756 X-Spam-Level: X-Spam-Status: No, score=-1.756 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fed1CvVVMLZI for ; Thu, 3 Apr 2008 16:06:30 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id C0F8328C6F8 for ; Thu, 3 Apr 2008 16:06:23 -0700 (PDT) Received: (qmail 10805 invoked from network); 3 Apr 2008 18:04:24 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 3 Apr 2008 18:04:24 -0400 From: "David B. Nelson" To: References: <00d701c89389$9f805710$0600a8c0@china.huawei.com><001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2><017101c89464$6d185210$0600a8c0@china.huawei.com><038f01c894cb$7cbc5b50$6401a8c0@NEWTON603> <020401c894df$ddb391d0$0600a8c0@china.huawei.com> Date: Thu, 3 Apr 2008 18:02:19 -0400 Organization: Elbrys Networks, Inc. Message-ID: <00b001c895d6$62a32c60$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <020401c894df$ddb391d0$0600a8c0@china.huawei.com> Thread-Index: AciTiZ79SOFZmNc6RJWNJ4eQ2H0HlQAl2/IgAAW7hyAAI4RgQAADAIBQAEBgE2A= Subject: [Isms] What granularity of attributes do we need for the secure transport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington writes... > I am concerned that dropping the choice of transport protocol really > limits how we can communicate with the lower layer to get information > we need to determine what level of access control should be applied. > "any protocol that provides transport layer encryption" may not be > good enough for operators. We need to have a further discussion of this issue on the list, and I have the action item start a thread to discuss it. Let's start that discussion now. I have a couple of thoughts to start off: -- If it turns out that we need something more granular than Management-Transport-Protection = {No-Protection | Integrity-Protection | Integrity-Confidentiality-Protection} to address the specific needs of SNMP, could we at that point in time extend the list of enumerated values for the Management-Transport-Protection to include special cases for SNMP? That would eliminate the need to restore the Management-Transport-Protocol attribute which caused a number of difficulties in terms of management transports other than those used for SNMP. Once you specify the protocol, then you logically need to specify all sorts of other protocol and security related parameters. I think we don't want to go down that path. -- Why do we think that RADIUS authorization should be used to provision specific secure transport properties, such as protocol, cipher suite, authentication mechanism, certificate chains, etc? It seems to me that these choices, while important to get right, do not need to be conveyed on each and every user access to the managed entity. They would typically be configured and left static for long periods of time. Yes, it is required that both ends of any such connection agree on the parameters, but it seems RADIUS authorization is not the optimal way to ensure that. I think that the choice that needs to be made on an access by access basis is simply whether or not the access needs to be secure. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Apr 3 17:41:07 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7FF28C3EE; Thu, 3 Apr 2008 17:41:07 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B339328C3B6 for ; Thu, 3 Apr 2008 17:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[AWL=1.488, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENvd681n2rr9 for ; Thu, 3 Apr 2008 17:41:05 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id CF6D128C3DA for ; Thu, 3 Apr 2008 17:41:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=QOYQmJnHxzGP/b/M3eqrfhagynKSbRzHczJeazXKrPzfsID3Z8RG0JvQLcaDkIxN; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.136.183] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JhZzR-0000cB-1i for isms@ietf.org; Thu, 03 Apr 2008 20:41:09 -0400 Message-ID: <003401c895ec$9a92edc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <00d701c89389$9f805710$0600a8c0@china.huawei.com><001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2><017101c89464$6d185210$0600a8c0@china.huawei.com><038f01c894cb$7cbc5b50$6401a8c0@NEWTON603><020401c894df$ddb391d0$0600a8c0@china.huawei.com><00b001c895d6$62a32c60$1f0a0a0a@xpsuperdvd2> <031001c895da$418f5220$0600a8c0@china.huawei.com> Date: Thu, 3 Apr 2008 17:41:20 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc8911771c0a44d54efb5d3907efca3314094ee350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.183 Subject: Re: [Isms] What granularity of attributes do we need for the securetransport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: "David Harrington" > To: "'David B. Nelson'" ; > Sent: Thursday, April 03, 2008 3:30 PM > Subject: Re: [Isms] What granularity of attributes do we need for the securetransport? > > In thinking about this, SNMP needs to know what "model" is used to > authentication, and it know sthat RADIUS is the "model". > > I think SNMP actually doesn't need to know how the encryption is done, > only that it is done. The operator can configure the underlying SSH or > other transport to use the approrpiate authentication and encryption > parameters. > > So this may actually be a non-issue. > Do others agree? ... As far as securityModel and securityName as used together in VACM, I'd agree. HOWEVER, securityModel is also used together with securityLevel (recall our wonderful ASCII art in section 3.1 of RFC 3415) to describe how information was (or will be) protected in transit, and this is an important factor in deciding whether to grant access. The strength of encryption provded by a given security model when the securityLevel is authPriv must be taken into account when formulating an access control policy. Consequently, from the choice of securityModel one needs to be able to, at the very least, infer what the minimum level of protection provided by authPriv would be. So I disagree with the assessment of this as a non-issue. Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 4 04:22:05 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BDE228C62A; Fri, 4 Apr 2008 04:22:05 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3FDE28C261 for ; Fri, 4 Apr 2008 04:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvdxA6tpBJTb for ; Fri, 4 Apr 2008 04:21:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 80E3928C3FC for ; Fri, 4 Apr 2008 04:21:59 -0700 (PDT) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 803AC8C83D; Fri, 4 Apr 2008 13:22:04 +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 09391-07; Fri, 4 Apr 2008 13:22:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5CAE78C843; Fri, 4 Apr 2008 13:22:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 61CAD52AC6F; Fri, 4 Apr 2008 13:22:01 +0200 (CEST) Date: Fri, 4 Apr 2008 13:22:01 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20080404112201.GB10840@elstar.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <031001c895da$418f5220$0600a8c0@china.huawei.com> <003401c895ec$9a92edc0$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <003401c895ec$9a92edc0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Cc: isms@ietf.org Subject: Re: [Isms] What granularity of attributes do we need for the securetransport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Thu, Apr 03, 2008 at 05:41:20PM -0700, Randy Presuhn wrote: > The strength of encryption provded by a given security model when the > securityLevel is authPriv must be taken into account when formulating > an access control policy. Consequently, from the choice of securityModel > one needs to be able to, at the very least, infer what the minimum level > of protection provided by authPriv would be. I like to point to the minutes of the ISMS meeting at the 64th IETF : [12] There was some notion in the room to allow SSH to always provide auth/priv services, even in cases where less is requested by the SNMP security level parameter. SSH supports a null cipher. The security considerations perhaps should explain that usage of the null cipher is generally not expected, even though implementations might support it for special cases (e.g. someone running ISMS over a secure IPsec tunnel or environments where encryption is illegal). Security people were in the room when this was discussed and part of the discussion was also that the SSHTM can blindly trust the SSH layer without having to peek into the internals of the session state. Since this meeting, we have worked under the assumption that the SSHTM can trust the SSH layer to provide proper security. Unless there is a major new argument, I would prefer to stick with this decision. /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 4 07:07:55 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9BE3A6A64; Fri, 4 Apr 2008 07:07:55 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3C4D3A6A64 for ; Fri, 4 Apr 2008 07:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yZ5VfvkCOJs for ; Fri, 4 Apr 2008 07:07:48 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 5C48F3A69A1 for ; Fri, 4 Apr 2008 07:07:47 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m34E7ldL008144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Apr 2008 10:07:48 -0400 (EDT) Date: Fri, 04 Apr 2008 10:07:47 -0400 From: Jeffrey Hutzelman To: j.schoenwaelder@jacobs-university.de, Randy Presuhn Message-ID: <72FE59E4EC77F8E3B9528923@sirius.fac.cs.cmu.edu> In-Reply-To: <20080404112201.GB10840@elstar.local> References: <031001c895da$418f5220$0600a8c0@china.huawei.com> <003401c895ec$9a92edc0$6801a8c0@oemcomputer> <20080404112201.GB10840@elstar.local> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] What granularity of attributes do we need for the securetransport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Friday, April 04, 2008 01:22:01 PM +0200 Juergen Schoenwaelder wrote: > On Thu, Apr 03, 2008 at 05:41:20PM -0700, Randy Presuhn wrote: > >> The strength of encryption provded by a given security model when the >> securityLevel is authPriv must be taken into account when formulating >> an access control policy. Consequently, from the choice of securityModel >> one needs to be able to, at the very least, infer what the minimum level >> of protection provided by authPriv would be. > > I like to point to the minutes of the ISMS meeting at the 64th IETF > : > > [12] There was some notion in the room to allow SSH to always provide > auth/priv services, even in cases where less is requested by the > SNMP security level parameter. > > SSH supports a null cipher. The security considerations perhaps > should explain that usage of the null cipher is generally not > expected, even though implementations might support it for > special cases (e.g. someone running ISMS over a secure IPsec > tunnel or environments where encryption is illegal). SSH supports a "none" cipher, and imposes the following requirement: The "none" cipher is provided for debugging and SHOULD NOT be used except for that purpose. Its cryptographic properties are sufficiently described in [RFC2410], which will show that its use does not meet the intent of this protocol. I believe this is sufficient. And in fact, the situations in which an SSH implementation might reasonably violate that SHOULD are likely to apply equally well to SNMP as to any other use. > Security people were in the room when this was discussed and part of > the discussion was also that the SSHTM can blindly trust the SSH layer > without having to peek into the internals of the session state. Since > this meeting, we have worked under the assumption that the SSHTM can > trust the SSH layer to provide proper security. Unless there is a > major new argument, I would prefer to stick with this decision. I (still) think this is the right approach. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 4 07:11:01 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5012B28C162; Fri, 4 Apr 2008 07:11:01 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CAF43A6CAD for ; Fri, 4 Apr 2008 07:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3cScqVYOAMr for ; Fri, 4 Apr 2008 07:10:55 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id E888B3A6F9C for ; Fri, 4 Apr 2008 07:10:46 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m34EAksJ008263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Apr 2008 10:10:47 -0400 (EDT) Date: Fri, 04 Apr 2008 10:10:46 -0400 From: Jeffrey Hutzelman To: "David B. Nelson" , isms@ietf.org Message-ID: <1A2CFA6602126FFD0425DDA7@sirius.fac.cs.cmu.edu> In-Reply-To: <00b001c895d6$62a32c60$1f0a0a0a@xpsuperdvd2> References: <00d701c89389$9f805710$0600a8c0@china.huawei.com> <001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2> <017101c89464$6d185210$0600a8c0@china.huawei.com> <038f01c894cb$7cbc5b50$6401a8c0@NEWTON603> <020401c894df$ddb391d0$0600a8c0@china.huawei.com> <00b001c895d6$62a32c60$1f0a0a0a@xpsuperdvd2> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: jhutz@cmu.edu Subject: Re: [Isms] What granularity of attributes do we need for the secure transport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Thursday, April 03, 2008 06:02:19 PM -0400 "David B. Nelson" wrote: > -- Why do we think that RADIUS authorization should be used to provision > specific secure transport properties, such as protocol, cipher suite, > authentication mechanism, certificate chains, etc? I don't think we think that. I certainly don't. And in practice, it can't provision those things, at least for SSH, because they are negotiated well before RADIUS gets involved. The best an implementation could do is fail authentication if the already-established connection doesn't meet the requirements described by RADIUS, and really, if you're going to do that, the right solution is to configure the SSH server correctly in the first place so that it negotiates an acceptable connection. While it might be useful to centralize management of configuration parameters such as which algorithms the SSH server is willing to support, RADIUS is not the right tool for doing so. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 4 08:43:19 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B950C3A6FB3; Fri, 4 Apr 2008 08:43:19 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E07C3A63EC for ; Fri, 4 Apr 2008 08:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC-wYTNscPxV for ; Fri, 4 Apr 2008 08:43:11 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 8FC8428C74E for ; Fri, 4 Apr 2008 08:41:07 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA04.westchester.pa.mail.comcast.net with comcast id 9RF71Z03W16LCl05405L00; Fri, 04 Apr 2008 15:39:43 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.westchester.pa.mail.comcast.net with comcast id 9Th71Z00E4HwxpC3S00000; Fri, 04 Apr 2008 15:41:12 +0000 X-Authority-Analysis: v=1.0 c=1 a=r0J6XT9COlAA:10 a=48vgC7mUAAAA:8 a=CYdLI6RNJIP55HHthskA:9 a=o4BmGHuKZNdyt7HWs0QA:7 a=pNyZFU2uM9YH18SH8kefVmoIZKwA:4 a=lZB815dzVvQA:10 a=-utQw5L2n1AA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Jeffrey Hutzelman'" , "'David B. Nelson'" , References: <00d701c89389$9f805710$0600a8c0@china.huawei.com><001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2><017101c89464$6d185210$0600a8c0@china.huawei.com><038f01c894cb$7cbc5b50$6401a8c0@NEWTON603><020401c894df$ddb391d0$0600a8c0@china.huawei.com><00b001c895d6$62a32c60$1f0a0a0a@xpsuperdvd2> <1A2CFA6602126FFD0425DDA7@sirius.fac.cs.cmu.edu> Date: Fri, 4 Apr 2008 11:41:07 -0400 Message-ID: <037d01c8966a$4d0b11d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <1A2CFA6602126FFD0425DDA7@sirius.fac.cs.cmu.edu> thread-index: AciWXb72aIumfr7ySgavZNRm18UwfAABfApQ Subject: Re: [Isms] What granularity of attributes do we need for the secure transport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I certainly have never argued that we should provision such things, except the protocol. Question #1: I think the difference in security properties between TLS, SSH, IPsec, and other "secure transports" are sufficiently large that an operator might want the ability to say "I approve this service as long as it is carried over SSH" rather than "I approve this service as long as it is carried over ANY protocol that provides encryption and integrity checking". The security considerations for these protocols might identify environments in which the protocol is not applicable because of some inherent design issue; for an operator running an NM protocol in that environment, should they have the ability to say "gee, my environment has that vulnerability, so I want to ensure an applicable secure transport is used"? Question #2: What exactly qualifies as a secure transport? I have mentioned TLS, SSH, and IPsec even though these are at different layers. If IEEE 802.1 provides a protocol for integrity checking and encrypting at layer 2, should I consider that to be sufficient to meet the integrity-and-confidentiality requirement for RADIUS, even if I have no transport model prepared to deal with layer 2 protocol security? Question #3: In SNMPv3, we made the decision to not try to judge the strength of security protocols, because it is a constantly moving and subjective target. We chose instead to accept the noAuthNopriv/authNoPriv/authPriv requirement and assertion approach. The proposal to use RADIUS attributes for integrity-and-confidentiality work roughly the same way. In the SNMPv3 case, we use the authPriv flags in the SNMPv3 message to say these properties MUST be met; in the RADIUS case, the requirements are specified in RADIUS attributes. If I understand correctly, in both cases, it is up to the SNMP security model (now in concert with the transport model) to ensure the requirements are met, and to assert to the ACM system that such is the case, without telling the ACM which protocols or ciphers or ... were used. Are the circumstances with RADIUS sufficiently different that the require/assert model used for Community amd USM is no longer adequate? Question #4: In the Community and USM cases, the auth and priv services were provided as part of the SNMP engine; now we are proposing outsourcing those to "secure transports". In USM, it is up to an operator to configure the user table to specify which auth and priv protocols/mechanisms are acceptable; in the outsource model, the operators may need to do that type of configuration in the SSH or TLS or IPsec configuration. Is this acceptable? Question #5: In the Community and USM security models, the user table configuration specified acceptable protocols/mechanisms that are suitable **for use with the SNMP engine**. In the TSM model, we migth expect the operators to handle configuration outside SNMP. However, those same protocols might be used for environments other than SNMP, so the acceptable mechansisms for SSH general use might be different than acceptable mechansisms for SSH for SNMP use. Is there really a difference that operators would want to be able to specify different requirements for the secure transport configuration, when used with SNMP (or another NM protocol)? dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Jeffrey Hutzelman > Sent: Friday, April 04, 2008 10:11 AM > To: David B. Nelson; isms@ietf.org > Cc: jhutz@cmu.edu > Subject: Re: [Isms] What granularity of attributes do we need > for the secure transport? > > --On Thursday, April 03, 2008 06:02:19 PM -0400 "David B. Nelson" > wrote: > > > -- Why do we think that RADIUS authorization should be used > to provision > > specific secure transport properties, such as protocol, > cipher suite, > > authentication mechanism, certificate chains, etc? > > I don't think we think that. I certainly don't. And in > practice, it can't > provision those things, at least for SSH, because they are > negotiated well > before RADIUS gets involved. The best an implementation > could do is fail > authentication if the already-established connection doesn't meet the > requirements described by RADIUS, and really, if you're going > to do that, > the right solution is to configure the SSH server correctly > in the first > place so that it negotiates an acceptable connection. > > While it might be useful to centralize management of configuration > parameters such as which algorithms the SSH server is willing > to support, > RADIUS is not the right tool for doing so. > > -- Jeff > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 4 08:52:09 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7E4E3A68BD; Fri, 4 Apr 2008 08:52:09 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C01473A6867 for ; Fri, 4 Apr 2008 08:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vtg1ONC2P3gw for ; Fri, 4 Apr 2008 08:52:04 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id D352D3A68BD for ; Fri, 4 Apr 2008 08:52:03 -0700 (PDT) Received: (qmail 28618 invoked from network); 4 Apr 2008 10:52:08 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 4 Apr 2008 10:52:08 -0400 From: "David B. Nelson" To: References: <00d701c89389$9f805710$0600a8c0@china.huawei.com> <001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2> <017101c89464$6d185210$0600a8c0@china.huawei.com> <038f01c894cb$7cbc5b50$6401a8c0@NEWTON603> <020401c894df$ddb391d0$0600a8c0@china.huawei.com> <00b001c895d6$62a32c60$1f0a0a0a@xpsuperdvd2> <1A2CFA6602126FFD0425DDA7@sirius.fac.cs.cmu.edu> Date: Fri, 4 Apr 2008 10:50:00 -0400 Organization: Elbrys Networks, Inc. Message-ID: <000601c89663$28a611c0$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1A2CFA6602126FFD0425DDA7@sirius.fac.cs.cmu.edu> Thread-Index: AciWXbCo5E+oNyrNTHONnYu9qpQ/NwABLyQg Cc: 'Jeffrey Hutzelman' Subject: Re: [Isms] What granularity of attributes do we need for the secure transport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Jeffrey Hutzelman writes... > The best an implementation could do is fail authentication if the > already-established connection doesn't meet the requirements described > by RADIUS... Yes, exactly. The NAS checks to see that the already established [SSH] connection meets the minimum security requirements provisioned in the RADIUS Access-Accept message. If that check fails, the NAS SHOULD behave as if an Access-Reject message had been received. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 4 09:07:01 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F653A68EE; Fri, 4 Apr 2008 09:07:00 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B7B3A6A7D for ; Fri, 4 Apr 2008 09:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.54 X-Spam-Level: X-Spam-Status: No, score=-1.54 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, J_CHICKENPOX_28=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh8UHnKnIX0q for ; Fri, 4 Apr 2008 09:06:49 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 211143A6AB1 for ; Fri, 4 Apr 2008 09:06:47 -0700 (PDT) Received: (qmail 31335 invoked from network); 4 Apr 2008 12:06:53 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 4 Apr 2008 12:06:53 -0400 From: "David B. Nelson" To: References: <00d701c89389$9f805710$0600a8c0@china.huawei.com><001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2><017101c89464$6d185210$0600a8c0@china.huawei.com><038f01c894cb$7cbc5b50$6401a8c0@NEWTON603><020401c894df$ddb391d0$0600a8c0@china.huawei.com><00b001c895d6$62a32c60$1f0a0a0a@xpsuperdvd2> <1A2CFA6602126FFD0425DDA7@sirius.fac.cs.cmu.edu> <037d01c8966a$4d0b11d0$0600a8c0@china.huawei.com> Date: Fri, 4 Apr 2008 12:04:45 -0400 Organization: Elbrys Networks, Inc. Message-ID: <002301c8966d$998dd530$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <037d01c8966a$4d0b11d0$0600a8c0@china.huawei.com> Thread-Index: AciWXb72aIumfr7ySgavZNRm18UwfAABfApQAAGnR7A= Cc: Bernard_Aboba@hotmail.com, 'Jeffrey Hutzelman' Subject: Re: [Isms] What granularity of attributes do we need for the secure transport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington writes... > I certainly have never argued that we should provision such > things, except the protocol. I know that, but Bernard Aboba made such an argument in his review comments of the -00 or -01 version of the RADEXT Management Authorization draft. He argued that once you can specify the transport protocol, you logically need to specify various properties of the protocol. The general consensus in RADEXT was that we didn't want to go down that path. As Jeff Hutzelman pointed out in one of his recent posts, RADIUS is probably not the right tool to be configuring all those security parameters of transport protocols. My concern with re-introducing the Management-Transport-Protocol attribute is that it brings baggage with it, including the need to address Bernard's comments. > Question #1: I think the difference in security properties between > TLS, SSH, IPsec, and other "secure transports" are sufficiently large > that an operator might want the ability to say "I approve this service > as long as it is carried over SSH" rather than "I approve this service > as long as it is carried over ANY protocol that provides encryption > and integrity checking". The security considerations for these > protocols might identify environments in which the protocol is not > applicable because of some inherent design issue; for an operator > running an NM protocol in that environment, should they have the > ability to say "gee, my environment has that vulnerability, so I want > to ensure an applicable secure transport is used"? I think your point has validity. Operators may well want to configure different secure transport protocols, depending on the environment. At this moment, ISMS is only standardizing SSH for use with SNMP, but the general problem space would include other protocols, and there are various security properties of SSH that can be co0nfigured. My question is whether this sort of configuration of the secure transport protocol is something that needs to be checked by the NAS, using differing criteria, on each and every user authentication? I think that granularity of configuration is generally handled by, well... configuration, and not handled as part of user authorization. > Question #2: What exactly qualifies as a secure transport? I have > mentioned TLS, SSH, and IPsec even though these are at different > layers. If IEEE 802.1 provides a protocol for integrity checking and > encrypting at layer 2, should I consider that to be sufficient to meet > the integrity-and-confidentiality requirement for RADIUS, even if I > have no transport model prepared to deal with layer 2 protocol > security? There are really two questions here. One is whether any given secure transport (possibly including Layer 2) is sufficient to address the security threat model of the particular deployment scenario. The other is whether there is a standardized SNMP Transport Model that allows the SNMP engine to "know" that a secure transport is being used. > Question #3: In SNMPv3, we made the decision to not try to judge the > strength of security protocols, because it is a constantly moving and > subjective target. We chose instead to accept the > noAuthNopriv/authNoPriv/authPriv requirement and assertion approach. Right. > The proposal to use RADIUS attributes for > integrity-and-confidentiality work roughly the same way. Yes. > In the SNMPv3 case, we use the authPriv flags in the SNMPv3 message > to say these properties MUST be met; in the RADIUS case, the > requirements are specified in RADIUS attributes. If I understand > correctly, in both cases, it is up to the SNMP security model (now > in concert with the transport model) to ensure the requirements are > met, and to assert to the ACM system that such is the case, without > telling the ACM which protocols or ciphers or ... were used. I think that's right. > Are the circumstances with RADIUS sufficiently different that the > require/assert model used for Community and USM is no longer adequate? I see no reason to believe so. > Question #4: In the Community and USM cases, the auth and priv > services were provided as part of the SNMP engine; now we are > proposing outsourcing those to "secure transports". In USM, it is up > to an operator to configure the user table to specify which auth and > priv protocols/mechanisms are acceptable; in the outsource model, the > operators may need to do that type of configuration in the SSH or TLS > or IPsec configuration. Is this acceptable? Well, when you're outsourcing... > Question #5: In the Community and USM security models, the user table > configuration specified acceptable protocols/mechanisms that are > suitable **for use with the SNMP engine**. In the TSM model, we might > expect the operators to handle configuration outside SNMP. However, > those same protocols might be used for environments other than SNMP, > so the acceptable mechanisms for SSH general use might be different > than acceptable mechanisms for SSH for SNMP use. Is there really a > difference that operators would want to be able to specify different > requirements for the secure transport configuration, when used with > SNMP (or another NM protocol)? That's a good question. I would think that if SSH is used for other forms of remote management (e.g. CLI) that what's "good for the goose is good for the gander". ;-) _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 4 10:26:37 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6D23A69C3; Fri, 4 Apr 2008 10:26:37 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9093A69C3 for ; Fri, 4 Apr 2008 10:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUlApVo8GDnx for ; Fri, 4 Apr 2008 10:26:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E33FB3A68C8 for ; Fri, 4 Apr 2008 10:26:34 -0700 (PDT) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A3758C698; Fri, 4 Apr 2008 19:26:40 +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 29070-01; Fri, 4 Apr 2008 19:26:39 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B127C8BAE4; Fri, 4 Apr 2008 19:26:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6E6E452B788; Fri, 4 Apr 2008 19:26:37 +0200 (CEST) Date: Fri, 4 Apr 2008 19:26:37 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20080404172637.GB11552@elstar.local> Mail-Followup-To: David Harrington , 'Jeffrey Hutzelman' , "'David B. Nelson'" , isms@ietf.org References: <1A2CFA6602126FFD0425DDA7@sirius.fac.cs.cmu.edu> <037d01c8966a$4d0b11d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <037d01c8966a$4d0b11d0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Cc: isms@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [Isms] What granularity of attributes do we need for the secure transport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Fri, Apr 04, 2008 at 11:41:07AM -0400, David Harrington wrote: > I certainly have never argued that we should provision such things, > except the protocol. Speaking as technical contributor... I think it is important to not confuse the configuration of say an SNMP engine or an SSH implementation with RADIUS authentication / authorization decisions. Certain things can very well be handled via configuration. /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 4 10:40:57 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BF4E3A6AAC; Fri, 4 Apr 2008 10:40:57 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42DF3A6896 for ; Fri, 4 Apr 2008 10:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIvxziJ+N7pR for ; Fri, 4 Apr 2008 10:40:54 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id DA48928C21F for ; Fri, 4 Apr 2008 10:40:25 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA08.westchester.pa.mail.comcast.net with comcast id 9SQ71Z0060EZKEL5809200; Fri, 04 Apr 2008 17:39:30 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA01.westchester.pa.mail.comcast.net with comcast id 9VgT1Z00G4HwxpC3M00000; Fri, 04 Apr 2008 17:40:31 +0000 X-Authority-Analysis: v=1.0 c=1 a=REkrsmf7qwEA:10 a=j3Z76cjpAAAA:8 a=UnJyG7-5Vsg7S08h7UIA:9 a=m2rFFA1PlV_BPHAeayybL1SC7qsA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <1A2CFA6602126FFD0425DDA7@sirius.fac.cs.cmu.edu> <037d01c8966a$4d0b11d0$0600a8c0@china.huawei.com> <20080404172637.GB11552@elstar.local> Date: Fri, 4 Apr 2008 13:40:27 -0400 Message-ID: <038c01c8967a$f8b95090$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <20080404172637.GB11552@elstar.local> thread-index: AciWeRBg/P7z/v4TRjSCSwEE+iDxZAAAYdLw Cc: isms@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [Isms] What granularity of attributes do we need for thesecure transport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, You are right. The wording I used was poor. I do not believe we need to provision the security protocl; I think we should allow an operator to decide which secure transport they want to require as a conditon of granting access to the SNMP service. How that secure transport is configured to deliver certain properties is out of scope. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, April 04, 2008 1:27 PM > To: David Harrington > Cc: 'Jeffrey Hutzelman'; 'David B. Nelson'; isms@ietf.org > Subject: Re: [Isms] What granularity of attributes do we need > for thesecure transport? > > On Fri, Apr 04, 2008 at 11:41:07AM -0400, David Harrington wrote: > > > I certainly have never argued that we should provision such things, > > except the protocol. > > Speaking as technical contributor... > > I think it is important to not confuse the configuration of say an > SNMP engine or an SSH implementation with RADIUS authentication / > authorization decisions. Certain things can very well be handled via > configuration. > > /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 4 10:59:30 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8244F3A6D9D; Fri, 4 Apr 2008 10:59:30 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4836D3A6D9D for ; Fri, 4 Apr 2008 10:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.737, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq85YzTDyxqO for ; Fri, 4 Apr 2008 10:59:29 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 5300A3A6B8F for ; Fri, 4 Apr 2008 10:59:29 -0700 (PDT) Received: (qmail 1771 invoked from network); 4 Apr 2008 13:59:35 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 4 Apr 2008 13:59:35 -0400 From: "David B. Nelson" To: References: <1A2CFA6602126FFD0425DDA7@sirius.fac.cs.cmu.edu> <037d01c8966a$4d0b11d0$0600a8c0@china.huawei.com> <20080404172637.GB11552@elstar.local> <038c01c8967a$f8b95090$0600a8c0@china.huawei.com> Date: Fri, 4 Apr 2008 13:57:27 -0400 Organization: Elbrys Networks, Inc. Message-ID: <002801c8967d$58006b40$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <038c01c8967a$f8b95090$0600a8c0@china.huawei.com> Thread-Index: AciWeRBg/P7z/v4TRjSCSwEE+iDxZAAAYdLwAAAep4A= Subject: Re: [Isms] What granularity of attributes do we need for the secure transport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington writes... > I do not believe we need to provision the security protocol; ... Meaning we don't need to specify such things as the selection of optional modes, cipher suite, authentication mechanism, certificate chains, and so forth. Right? > I think we should allow an operator to decide which secure transport > they want to require as a condition of granting access to the SNMP > service. Just the transport protocol name? Or do you want to sub-specify versions, e.g. SSHv2, TLSv1? If you want to specify IPsec as one of these, do you need to specify such things as IKEv2? I think the devil is in the details. If I understand your position correctly, to want to augment the existing Management-Protocol-Protection attribute, which specifies the level of security in an abstract fashion, with a reinstated Management-Transport-Protocol attribute which names the mandated protocol (and maybe the protocol version). Right? Do you anticipate that there could be only one of these attributes in a RADIUS Access-Accept message, or could there be more than one (i.e. acceptable alternatives)? That seems to be a middle ground choice, between having only an abstract assertion about the security level and having all the details and parameters related to a secure transport protocol. What do others think about this decision point? -- Do we need only an abstract security level assertion? -- Do we need the transport protocol name? -- Do we need the transport protocol version? -- Do we need any further details of security parameters? _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 4 11:46:08 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6291A28C2DD; Fri, 4 Apr 2008 11:46:08 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3F228C230 for ; Fri, 4 Apr 2008 11:46:07 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMSImmkCUxEP for ; Fri, 4 Apr 2008 11:46:06 -0700 (PDT) Received: from bay0-omc1-s14.bay0.hotmail.com (bay0-omc1-s14.bay0.hotmail.com [65.54.246.86]) by core3.amsl.com (Postfix) with ESMTP id B48453A6B8F for ; Fri, 4 Apr 2008 11:46:06 -0700 (PDT) Received: from hotmail.com ([10.4.31.17]) by bay0-omc1-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 11:46:13 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 4 Apr 2008 11:46:12 -0700 Message-ID: Received: from 131.107.0.105 by BLU137-DAV7.phx.gbl with DAV; Fri, 04 Apr 2008 18:46:11 +0000 X-Originating-IP: [131.107.0.105] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: "'David B. Nelson'" , References: <00d701c89389$9f805710$0600a8c0@china.huawei.com><001101c89430$c4acd020$1f0a0a0a@xpsuperdvd2><017101c89464$6d185210$0600a8c0@china.huawei.com><038f01c894cb$7cbc5b50$6401a8c0@NEWTON603><020401c894df$ddb391d0$0600a8c0@china.huawei.com><00b001c895d6$62a32c60$1f0a0a0a@xpsuperdvd2> <1A2CFA6602126FFD0425DDA7@sirius.fac.cs.cmu.edu> <037d01c8966a$4d0b11d0$0600a8c0@china.huawei.com> <002301c8966d$998dd530$1f0a0a0a@xpsuperdvd2> In-Reply-To: <002301c8966d$998dd530$1f0a0a0a@xpsuperdvd2> Date: Fri, 4 Apr 2008 11:46:11 -0700 Message-ID: <000f01c89684$2704bad0$750e3070$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciWXb72aIumfr7ySgavZNRm18UwfAABfApQAAGnR7AABiAO4A== Content-Language: en-us X-OriginalArrivalTime: 04 Apr 2008 18:46:12.0612 (UTC) FILETIME=[27B59440:01C89684] Cc: radiusext@ops.ietf.org, 'Jeffrey Hutzelman' Subject: Re: [Isms] What granularity of attributes do we need for the secure transport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Nelson spoke thusly: "My question is whether this sort of configuration of the secure transport protocol is something that needs to be checked by the NAS, using differing criteria, on each and every user authentication? I think that granularity of configuration is generally handled by, well... configuration, and not handled as part of user authorization." With respect to IEEE 802.11 access, there are no RADIUS attributes that specify whether a given user is allowed to do WEP/WPA/WPA2. It is assumed that security is negotiated between the AP and STA based on their configuration. This seems to work OK, particularly since separate SSIDs are typically provisioned for each supported security mechanism, so that user authorization can be handled based on the SSID (provided in the Called-Station-Id). A similar approach might well work here -- we assume that the NAS is set up to allow/require various security mechanisms. It might be useful for the NAS to tell the RADIUS server what security mechanism has been negotiated, and the RADIUS server might Accept/Reject the authentication based on that information as well as the user-name. But there is no notion that the RADIUS server can exercise *control* over what is negotiated -- it is "here is what I'm doing, take it or leave it". _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 4 11:46:40 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9050028C134; Fri, 4 Apr 2008 11:46:40 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04063A6B8F for ; Fri, 4 Apr 2008 11:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCl6p5qrGugq for ; Fri, 4 Apr 2008 11:46:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F123A3A6B86 for ; Fri, 4 Apr 2008 11:46:37 -0700 (PDT) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4C968C811; Fri, 4 Apr 2008 20:46:43 +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 32589-02; Fri, 4 Apr 2008 20:46:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A74998C768; Fri, 4 Apr 2008 20:46:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A67C552B838; Fri, 4 Apr 2008 20:46:41 +0200 (CEST) Date: Fri, 4 Apr 2008 20:46:41 +0200 From: Juergen Schoenwaelder To: "David B. Nelson" Message-ID: <20080404184641.GA11719@elstar.local> Mail-Followup-To: "David B. Nelson" , isms@ietf.org References: <1A2CFA6602126FFD0425DDA7@sirius.fac.cs.cmu.edu> <037d01c8966a$4d0b11d0$0600a8c0@china.huawei.com> <20080404172637.GB11552@elstar.local> <038c01c8967a$f8b95090$0600a8c0@china.huawei.com> <002801c8967d$58006b40$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <002801c8967d$58006b40$1f0a0a0a@xpsuperdvd2> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Cc: isms@ietf.org Subject: Re: [Isms] What granularity of attributes do we need for the secure transport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Fri, Apr 04, 2008 at 01:57:27PM -0400, David B. Nelson wrote: > What do others think about this decision point? > > -- Do we need only an abstract security level assertion? > > -- Do we need the transport protocol name? > > -- Do we need the transport protocol version? > > -- Do we need any further details of security parameters? As technical contributor, I like the abstract security level assertion. More granular control can be achieved by means of configuration of the SNMP engine or secure transport protocol. /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Apr 8 09:49:10 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF103A6D61; Tue, 8 Apr 2008 09:49:10 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD51F28C164 for ; Tue, 8 Apr 2008 09:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aym9hFo63L2n for ; Tue, 8 Apr 2008 09:49:08 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id EB2563A6ADF for ; Tue, 8 Apr 2008 09:49:07 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id CFA8B399BD8; Tue, 8 Apr 2008 09:49:04 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=jZD+UwyCZCu6S6wGHqO9HvTBWyk=; b=oZIsbmV53QmBhcg3z25pI/xyvk3Dqy7MEBlsOW9ef3ALrYZdqe4RVTXqXuTthfBoTQ6v4jN5hw6BSBv57BXY37azqode7C9BTzplo4Fl6alT3kAlvXavAZfyQy2mrMFpyhDl+iZkXF2fugz72Giubbguf4RBaJqmNXmFuWhyCJA= Received: by wes.hardakers.net (Postfix, from userid 274) id 7F8FE399C50; Tue, 8 Apr 2008 09:49:04 -0700 (PDT) From: Wes Hardaker To: Randy Presuhn Organization: Sparta References: <031001c895da$418f5220$0600a8c0@china.huawei.com> <003401c895ec$9a92edc0$6801a8c0@oemcomputer> <20080404112201.GB10840@elstar.local> Date: Tue, 08 Apr 2008 09:49:04 -0700 In-Reply-To: <20080404112201.GB10840@elstar.local> (Juergen Schoenwaelder's message of "Fri, 4 Apr 2008 13:22:01 +0200") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] What granularity of attributes do we need for the securetransport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> "JS" == Juergen Schoenwaelder writes: JS> Security people were in the room when this was discussed and part of JS> the discussion was also that the SSHTM can blindly trust the SSH layer JS> without having to peek into the internals of the session state. Since JS> this meeting, we have worked under the assumption that the SSHTM can JS> trust the SSH layer to provide proper security. Unless there is a JS> major new argument, I would prefer to stick with this decision. In particular, if you're going to outsource the complexity of security to another protocol, which is being done by using SSH as a transport. You either have to trust that transport to do the right thing or you are going to fail to actually outsource much of the complexity in the first place. Plus if you strictly require only certain modes of the lower transport then when it gets security upgrades (eg, new algorithms) you won't because you too exactly specified requirements of it. I think if the lower level says it can support authPriv you simply have to trust it. Doing anything else adds way too much complexity and layer interaction that isn't needed. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Apr 8 11:14:47 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5656228C2F5; Tue, 8 Apr 2008 11:14:47 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97FB428C2F5 for ; Tue, 8 Apr 2008 11:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.903 X-Spam-Level: X-Spam-Status: No, score=-2.903 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDX59oQd7oLr for ; Tue, 8 Apr 2008 11:14:44 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 85AA028C2D3 for ; Tue, 8 Apr 2008 11:14:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=V3u2IGBsptcj4wVrDII9Q/jiSJfGEoZKqn3VdKHljkFdHgLQUHeEC8nJn4RIJLCK; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.83.27] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JjILR-0001bu-DL for isms@ietf.org; Tue, 08 Apr 2008 14:14:57 -0400 Message-ID: <001a01c8999c$22b38f40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <031001c895da$418f5220$0600a8c0@china.huawei.com><003401c895ec$9a92edc0$6801a8c0@oemcomputer><20080404112201.GB10840@elstar.local> Date: Tue, 8 Apr 2008 11:15:24 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117b259b24a5d71ed81048130d04f44f882350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.83.27 Subject: Re: [Isms] What granularity of attributes do we need for the securetransport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: "Wes Hardaker" > To: "Randy Presuhn" > Cc: > Sent: Tuesday, April 08, 2008 10:49 AM > Subject: Re: [Isms] What granularity of attributes do we need for the securetransport? ... > In particular, if you're going to outsource the complexity of security > to another protocol, which is being done by using SSH as a transport. > You either have to trust that transport to do the right thing or you are > going to fail to actually outsource much of the complexity in the first > place. Plus if you strictly require only certain modes of the lower > transport then when it gets security upgrades (eg, new algorithms) you > won't because you too exactly specified requirements of it. > > I think if the lower level says it can support authPriv you simply have > to trust it. Doing anything else adds way too much complexity and layer > interaction that isn't needed. ... But it *also* means that the security administrator setting up an organization's access control policy has to be able to trust that all the "authPrivs" used by that lower layer within that organization are sufficiently strong for the information that the access control policy allows to be carried. If we don't say how that gets configured, then at least we need to make it known as an operational security consideration. Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Apr 8 14:06:26 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97BEA3A6B86; Tue, 8 Apr 2008 14:06:25 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 655F03A6B0A for ; Tue, 8 Apr 2008 14:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wvax1BeW9dm for ; Tue, 8 Apr 2008 14:06:21 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id D75083A6B86 for ; Tue, 8 Apr 2008 14:06:20 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 8F38B399BD8; Tue, 8 Apr 2008 14:06:25 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=HqXRi0rCv0pSMPLmRQ4iPOBHLpM=; b=QLAbm9/PDNwI4tt7Fq/A9REF0nfbb28LdeLpkEUy2Vp9kIHwR8X3zV14aOtb427dKFbJogYMqMVjpEIFDwHPwxQUDQV3XbmS2zN/OU36cD2XKPlnTm5oInldbrReLNxxuYrS50BfXTUWVmwNlBDUDJduJjxTWAfCrqpTXrISLhc= Received: by wes.hardakers.net (Postfix, from userid 274) id 5C7BD399C50; Tue, 8 Apr 2008 14:06:25 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" Organization: Sparta References: <031001c895da$418f5220$0600a8c0@china.huawei.com> <003401c895ec$9a92edc0$6801a8c0@oemcomputer> <20080404112201.GB10840@elstar.local> <001a01c8999c$22b38f40$6801a8c0@oemcomputer> Date: Tue, 08 Apr 2008 14:06:25 -0700 In-Reply-To: <001a01c8999c$22b38f40$6801a8c0@oemcomputer> (Randy Presuhn's message of "Tue, 8 Apr 2008 11:15:24 -0600") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] What granularity of attributes do we need for the securetransport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> "RP" == Randy Presuhn writes: RP> But it *also* means that the security administrator setting up an RP> organization's access control policy has to be able to trust that RP> all the "authPrivs" used by that lower layer within that RP> organization are sufficiently strong for the information that the RP> access control policy allows to be carried. RP> If we don't say how that gets configured, then at least we need to RP> make it known as an operational security consideration. Well, let me add the other half of my thoughts... It comes back to (as always) required vs optional. I do think it would be beneficial to throw in 100 optional tags that can be used to supply additional configuration for anything (transport security settings or otherwise). What I think would be wrong is if we required those to be present or the transport couldn't be used. Having them optional is fine since they can be turned off when new features get deployed by SSH (or whatever) that should be used instead. I should have stated this before... Ideally I'd want a decoupling of the transport setup parameters as much as possible with optional interfaces to be *able to* specify settings. I'd also agree that if they're specified they have to be used (or the transport can't be used if it's impossible... discarding values in security parameters because you don't understand or implement them is a recipe for distaster). -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Apr 8 16:23:48 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B203A6A98; Tue, 8 Apr 2008 16:23:48 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1436F3A6840 for ; Tue, 8 Apr 2008 16:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61dHuSOoOQYr for ; Tue, 8 Apr 2008 16:23:46 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id EE9D13A6817 for ; Tue, 8 Apr 2008 16:23:45 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA02.westchester.pa.mail.comcast.net with comcast id B9dY1Z0050mv7h05207d00; Tue, 08 Apr 2008 23:22:50 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.westchester.pa.mail.comcast.net with comcast id BBPy1Z00C4HwxpC3X00000; Tue, 08 Apr 2008 23:24:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=mX3Z4ubhF_EA:10 a=tfdp1Mlad6wA:10 a=48vgC7mUAAAA:8 a=piynG-8jdI376NqahyoA:9 a=2Og3DDoyiXgD2JDuLeAA:7 a=JFT-o9tSVerkthmiJfFJpyCK4c4A:4 a=lZB815dzVvQA:10 a=OS7PZEPQ3MUA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'Wes Hardaker'" , "'Randy Presuhn'" References: <031001c895da$418f5220$0600a8c0@china.huawei.com><003401c895ec$9a92edc0$6801a8c0@oemcomputer><20080404112201.GB10840@elstar.local><001a01c8999c$22b38f40$6801a8c0@oemcomputer> Date: Tue, 8 Apr 2008 19:23:58 -0400 Message-ID: <05ce01c899cf$9f4ad260$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: thread-index: AciZvHlqgHDKUFw0SoSHRv8zm9bbXwAEDM3w Cc: isms@ietf.org Subject: Re: [Isms] What granularity of attributes do we need forthe securetransport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, Let's keep in mind where this thread started. This is NOT about specifying all sorts of parameters for the security protocols and the mechanisms that they use. This is about what RADIUS specifies as requirements to be met for the service to be delivered by the NAS. If I have the relationship between the NAS (RADIUS client) and the RADIUS server correct, then the NAS asks the RADIUS server how the service to be provided must be provisioned before providing that service to the authenticated entity. In the case of the SSHTM, the service we are looking to have authorized is an SSH subsystem over which we want to run an SNMP session. It is specifically the SSHTM that is asking whether an SSH subsystem is authorized for this user. I don't know how we provide a "hint" that an SSH subsystem is what we want, without having an attribute to specify that is the protocol we are interested in running SNMP over. If we do not send a hint because there is no attribute for it, then is it appropriate for RADIUS to **only be able to** respond that "any transport protocol that provides integrity checking and encryption is fine for SNMP for this user"? dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Tuesday, April 08, 2008 5:06 PM > To: Randy Presuhn > Cc: isms@ietf.org > Subject: Re: [Isms] What granularity of attributes do we need > forthe securetransport? > > >>>>> "RP" == Randy Presuhn writes: > > RP> But it *also* means that the security administrator setting up an > RP> organization's access control policy has to be able to trust that > RP> all the "authPrivs" used by that lower layer within that > RP> organization are sufficiently strong for the information that the > RP> access control policy allows to be carried. > > RP> If we don't say how that gets configured, then at least we need to > RP> make it known as an operational security consideration. > > Well, let me add the other half of my thoughts... > > It comes back to (as always) required vs optional. I do > think it would > be beneficial to throw in 100 optional tags that can be used to supply > additional configuration for anything (transport security settings or > otherwise). What I think would be wrong is if we required those to be > present or the transport couldn't be used. Having them > optional is fine > since they can be turned off when new features get deployed by SSH (or > whatever) that should be used instead. I should have stated this > before... > > Ideally I'd want a decoupling of the transport setup > parameters as much > as possible with optional interfaces to be *able to* specify settings. > I'd also agree that if they're specified they have to be used (or the > transport can't be used if it's impossible... discarding values in > security parameters because you don't understand or implement > them is a > recipe for distaster). > -- > Wes Hardaker > Sparta, Inc. > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Apr 8 21:36:56 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 971EE3A6993; Tue, 8 Apr 2008 21:36:56 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3753A6782 for ; Tue, 8 Apr 2008 21:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.224 X-Spam-Level: X-Spam-Status: No, score=-1.224 tagged_above=-999 required=5 tests=[AWL=1.376, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdh+--Zbvq67 for ; Tue, 8 Apr 2008 21:36:55 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 25F1B3A68FB for ; Tue, 8 Apr 2008 21:36:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=FC/VAWXt6s820D88igHuhex2nDUxPhR/w+oWcX4CtzdGYqrkVScmdrNTrzrkxMR5; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.188.243] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JjS3Z-00085o-Vs for isms@ietf.org; Wed, 09 Apr 2008 00:37:10 -0400 Message-ID: <003a01c899f3$0fe61a20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <031001c895da$418f5220$0600a8c0@china.huawei.com><003401c895ec$9a92edc0$6801a8c0@oemcomputer><20080404112201.GB10840@elstar.local><001a01c8999c$22b38f40$6801a8c0@oemcomputer> <05ce01c899cf$9f4ad260$0600a8c0@china.huawei.com> Date: Tue, 8 Apr 2008 21:37:39 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc8911781ed3d657875d5d1de6e92f0067a087d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.243 Subject: Re: [Isms] What granularity of attributes do we need forthe securetransport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: "David Harrington" > To: "'Wes Hardaker'" ; "'Randy Presuhn'" > Cc: > Sent: Tuesday, April 08, 2008 5:23 PM > Subject: RE: [Isms] What granularity of attributes do we need forthe securetransport? ... > If we do not send a hint because there is no attribute for it, then is > it appropriate for RADIUS to **only be able to** respond that "any > transport protocol that provides integrity checking and encryption is > fine for SNMP for this user"? ... I think the corner we're painting ourselves into here is just as you describe it, and that providing a way to configure the systems in an administrative domain so that the actual security provided is known and adequate, while a legitimate operational concern which should be documented, is probably also something that the IETF won't ever get around to actually addressing. Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 9 06:34:06 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A64D28C4B1; Wed, 9 Apr 2008 06:34:06 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A396328C4B1 for ; Wed, 9 Apr 2008 06:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLB7wN9sBfxU for ; Wed, 9 Apr 2008 06:34:01 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 400FC28C4A5 for ; Wed, 9 Apr 2008 06:34:00 -0700 (PDT) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2BA408C83F; Wed, 9 Apr 2008 15:34:18 +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 08946-03; Wed, 9 Apr 2008 15:34:17 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C83258A46E; Wed, 9 Apr 2008 15:34:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D9F9952EF2D; Wed, 9 Apr 2008 15:34:15 +0200 (CEST) Date: Wed, 9 Apr 2008 15:34:15 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20080409133415.GA16117@elstar.local> Mail-Followup-To: David Harrington , 'Wes Hardaker' , 'Randy Presuhn' , isms@ietf.org References: <05ce01c899cf$9f4ad260$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <05ce01c899cf$9f4ad260$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Cc: isms@ietf.org Subject: Re: [Isms] What granularity of attributes do we need forthe securetransport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Tue, Apr 08, 2008 at 07:23:58PM -0400, David Harrington wrote: > If I have the relationship between the NAS (RADIUS client) and the > RADIUS server correct, then the NAS asks the RADIUS server how the > service to be provided must be provisioned before providing that > service to the authenticated entity. In the case of the SSHTM, the > service we are looking to have authorized is an SSH subsystem over > which we want to run an SNMP session. It is specifically the SSHTM > that is asking whether an SSH subsystem is authorized for this user. I > don't know how we provide a "hint" that an SSH subsystem is what we > want, without having an attribute to specify that is the protocol we > are interested in running SNMP over. I think this thinking is backwards. RADIUS is not a provisioning protocol as far as I can tell. Since the secure transport already exists when RADIUS comes into play, all we can reasonably do is ship information about the actual secure transport to the RADIUS server so that the RADIUS server can take this into account when it takes a decision. Radius experts, please correct me if I got this wrong. /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 9 06:39:15 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6685028C3CB; Wed, 9 Apr 2008 06:39:15 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE6F328C3CB for ; Wed, 9 Apr 2008 06:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osGZVfWF-g6z for ; Wed, 9 Apr 2008 06:39:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F22C928C17C for ; Wed, 9 Apr 2008 06:39:12 -0700 (PDT) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5514865C6; Wed, 9 Apr 2008 15:39:30 +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 09267-05; Wed, 9 Apr 2008 15:39:29 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6ED88A15F; Wed, 9 Apr 2008 15:39:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0E72752EFBB; Wed, 9 Apr 2008 15:39:29 +0200 (CEST) Date: Wed, 9 Apr 2008 15:39:28 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20080409133928.GB16117@elstar.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <001a01c8999c$22b38f40$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <001a01c8999c$22b38f40$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Cc: isms@ietf.org Subject: Re: [Isms] What granularity of attributes do we need for the securetransport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Tue, Apr 08, 2008 at 11:15:24AM -0600, Randy Presuhn wrote: > But it *also* means that the security administrator setting up an > organization's access control policy has to be able to trust that > all the "authPrivs" used by that lower layer within that > organization are sufficiently strong for the information that the > access control policy allows to be carried. > > If we don't say how that gets configured, then at least we need to > make it known as an operational security consideration. Randy, can you check the text in ? There is already text talking about this - if you think the text needs improvement, please post suggested changes. /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 9 07:57:07 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79F443A6B90; Wed, 9 Apr 2008 07:57:07 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 178483A6964 for ; Wed, 9 Apr 2008 07:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-Limlf0rjNz for ; Wed, 9 Apr 2008 07:57:04 -0700 (PDT) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id B0A633A6B90 for ; Wed, 9 Apr 2008 07:57:03 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA08.westchester.pa.mail.comcast.net with comcast id BPon1Z00L0vyq2s580Ap00; Wed, 09 Apr 2008 14:56:15 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id BSwx1Z0034HwxpC3R00000; Wed, 09 Apr 2008 14:57:01 +0000 X-Authority-Analysis: v=1.0 c=1 a=csjs7tfFTbIA:10 a=tfdp1Mlad6wA:10 a=j3Z76cjpAAAA:8 a=h2Fq056zsR8sXtgIUegA:9 a=PcGEINVRz1wPEyno03gA:7 a=pycZgJl8t-bdH9441oUpJew6j0YA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: References: <05ce01c899cf$9f4ad260$0600a8c0@china.huawei.com> <20080409133415.GA16117@elstar.local> Date: Wed, 9 Apr 2008 10:56:57 -0400 Message-ID: <05fe01c89a51$f544bb90$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <20080409133415.GA16117@elstar.local> thread-index: AciaRnC+QPVJYR/PSEy1i4i0p9rNZgAALJpg Cc: isms@ietf.org Subject: Re: [Isms] What granularity of attributes do we need forthesecuretransport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I want to make sure my choice of wording doesn't mislead. When I say "the NAS asks the RADIUS server how the service to be provided must be provisioned", I do NOT mean the RADIUS server provides provisioning information or tells the NAS how to subsequently provision the service. The RADIUS server says to the NAS "if your configuration of the service meets these requirements, then you can deliver the service to this user; if your configuration does not meet these requirements, then you MUST NOT deliver this service to this user". -- I am trying to understand where the responsibilities lie, to see if there is enough information to make the determination. Let me lapse in COPS-PR terminology, and think of RADIUS in terms of a policy decision point (PDP) at the RADIUS server and a policy enforcement point (PEP) at the NAS. So the RADIUS server must be configured to act as the policy decision point, while the NAS must be configured to act as the policy enforcement point. RADIUS only tells us the operators' policy for the service for the authenticated user; the NAS enforces the policy. Operators have the responsibility to configure the RADIUS server to specify the policy for "service to this user", and to configure the security available on the NAS to enforce the policy. -- Let's first consider whether the NAS can enforce the RADIUS policy: The SNMP transport/security models have the responsibility to determine whether the transport meets the SNMP authPriv requirements. If RADIUS sends an access-accept, then we know we have auth. If the RADIUS policy says "integrity+confidentiality", the transport/security model must check the transport to see if priv is provided. If it is not, then we must treat this as an access-reject. Actually, the SNMP engine doesn't check this; we trust that the transport provides it if we request it in securityLevel for an outgoing message, and for incoming we trust authPriv is provided if tmStateReference says it is. But, we implicitly trust the transport layer because SNMP has no capability to verify the requirement sent in the RADIUS policy (so in SSHTM we fill in tmStateReference with a hard-coded value). This raises the question of whether it is appropriate for us to design a solution where RADIUS says "you MUST verify that the service meets these requirements" and then gives us a requirement we know we cannot check (because SNMP should not know any of the details of transport security). So should RADIUS even send this transport-protection policy to SNMP at runtime if we know SNMP cannot enforce this at runtime? Realistically, we don't need this attribute in RADIUS if all NM protocols will be expected to be similarly unable to *verify* how the security has been configured, because they also should have no knowledge of security configuration details. Right? Consistency of security properties across management interfaces is important to have holistic security. If other NM protocols, like the CLI, are expected to be able to actually verify the security configuration, then so should SNMP. And then it would make sense to have the transport-protection RADIUS attribute. If RADIUS can require, and other NM protocols can verify, other aspects of security configuration, then SNMP should also be able to verify those details. If RADIUS will specify requirements for the service, we MUST be able to verify we do meet the requirements. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, April 09, 2008 9:34 AM > To: David Harrington > Cc: 'Wes Hardaker'; 'Randy Presuhn'; isms@ietf.org > Subject: Re: [Isms] What granularity of attributes do we need > forthesecuretransport? > > On Tue, Apr 08, 2008 at 07:23:58PM -0400, David Harrington wrote: > > > If I have the relationship between the NAS (RADIUS client) and the > > RADIUS server correct, then the NAS asks the RADIUS server how the > > service to be provided must be provisioned before providing that > > service to the authenticated entity. In the case of the SSHTM, the > > service we are looking to have authorized is an SSH subsystem over > > which we want to run an SNMP session. It is specifically the SSHTM > > that is asking whether an SSH subsystem is authorized for > this user. I > > don't know how we provide a "hint" that an SSH subsystem is what we > > want, without having an attribute to specify that is the protocol we > > are interested in running SNMP over. > > I think this thinking is backwards. RADIUS is not a provisioning > protocol as far as I can tell. > > Since the secure transport already exists when RADIUS comes into play, > all we can reasonably do is ship information about the actual secure > transport to the RADIUS server so that the RADIUS server can take this > into account when it takes a decision. > > Radius experts, please correct me if I got this wrong. > > /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 9 08:17:54 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC7D28C480; Wed, 9 Apr 2008 08:17:54 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B4A3A692D for ; Wed, 9 Apr 2008 08:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiSyMt9-6JnE for ; Wed, 9 Apr 2008 08:17:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1133F3A699F for ; Wed, 9 Apr 2008 08:17:52 -0700 (PDT) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F4DD8C8A5; Wed, 9 Apr 2008 17:18:10 +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 15294-07; Wed, 9 Apr 2008 17:18:08 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E568E8C84C; Wed, 9 Apr 2008 17:18:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E322A52F321; Wed, 9 Apr 2008 17:18:06 +0200 (CEST) Date: Wed, 9 Apr 2008 17:18:06 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20080409151806.GB16331@elstar.local> Mail-Followup-To: David Harrington , 'Wes Hardaker' , 'Randy Presuhn' , isms@ietf.org References: <05ce01c899cf$9f4ad260$0600a8c0@china.huawei.com> <20080409133415.GA16117@elstar.local> <05fe01c89a51$f544bb90$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <05fe01c89a51$f544bb90$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Cc: isms@ietf.org Subject: Re: [Isms] What granularity of attributes do we need forthesecuretransport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Wed, Apr 09, 2008 at 10:56:57AM -0400, David Harrington wrote: > The RADIUS server says to the NAS "if your configuration of the > service meets these requirements, then you can deliver the service to > this user; if your configuration does not meet these requirements, > then you MUST NOT deliver this service to this user". But would it not make sense in the SNMP case that the RADIUS client says "I have user admin with auth/priv - shall I give her access?" and the RADIUS server says either "yes" or "no"? Do we need conditional yes answers, considering the fact that transport properties likely can't be changed? /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 9 08:20:50 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED32128C3BF; Wed, 9 Apr 2008 08:20:50 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A583A699F for ; Wed, 9 Apr 2008 08:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.732, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpbsoptheJ3G for ; Wed, 9 Apr 2008 08:20:49 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id CDFC63A6813 for ; Wed, 9 Apr 2008 08:20:27 -0700 (PDT) Received: (qmail 22642 invoked from network); 9 Apr 2008 11:20:45 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 9 Apr 2008 11:20:45 -0400 From: "David B. Nelson" To: References: <05ce01c899cf$9f4ad260$0600a8c0@china.huawei.com> <20080409133415.GA16117@elstar.local> Date: Wed, 9 Apr 2008 11:18:22 -0400 Organization: Elbrys Networks, Inc. Message-ID: <000601c89a54$f32381e0$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciaRm3D82Rln9jATf+OpTc2HmZsGwADFIkg In-Reply-To: <20080409133415.GA16117@elstar.local> Subject: Re: [Isms] What granularity of attributes do we need for the secure transport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Juergen Schoenwaelder writes... > I think this thinking is backwards. RADIUS is not a provisioning > protocol as far as I can tell. RADIUS is not a host provisioning protocol, in the way that SNMP or DHCP are, for example. It is a service provisioning protocol. That doesn't mean that RADIUS provisions the static configuration of services, but it does specify if and, to a limited extent, how a service is provided to a given authenticated user at a given time. > Since the secure transport already exists when RADIUS comes into play, > all we can reasonably do is ship information about the actual secure > transport to the RADIUS server so that the RADIUS server can take this > into account when it takes a decision. Yes. There are two ways in which the enforcement can occur. If the NAS sends suitably descriptive "hint" attributes in the Access-Request message, describing the service being requested, e.g. SNMP over a secure SNNP Transport Model, or SNMP over SSH, the RADIUS server can decide to send an Access-Reject if the user ought not to be provided with that service, or the user cannot be provided that service using the available transport. Alternately, the RADIUS server can send an Access-Accept message specifying the service the user is authorized to access and further conditions upon that access, such as the security properties of the transport. The NAS is obligated to enforce these service provisioning restrictions, and if it cannot, e.g. because the available transport fails to meet the security restrictions, it will then treat the Access-Accept as if it had been an Access-Reject. Thus, the final "go/no-go" decision can reside either at the RADIUS server or at the NAS, but in either case it is the RADIUS server that dictates the conditions of providing the service. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 9 09:01:25 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF91D28C477; Wed, 9 Apr 2008 09:01:25 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB8F28C49C for ; Wed, 9 Apr 2008 09:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.703, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Je19weT1jwv for ; Wed, 9 Apr 2008 09:01:23 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 0BC3A28C477 for ; Wed, 9 Apr 2008 09:01:22 -0700 (PDT) Received: (qmail 23572 invoked from network); 9 Apr 2008 12:01:41 -0400 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 9 Apr 2008 12:01:41 -0400 From: "David B. Nelson" To: References: <05ce01c899cf$9f4ad260$0600a8c0@china.huawei.com><20080409133415.GA16117@elstar.local> <05fe01c89a51$f544bb90$0600a8c0@china.huawei.com> Date: Wed, 9 Apr 2008 11:59:18 -0400 Organization: Elbrys Networks, Inc. Message-ID: <001b01c89a5a$aaed1f20$1f0a0a0a@xpsuperdvd2> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciaRnC+QPVJYR/PSEy1i4i0p9rNZgAALJpgAASulLA= In-Reply-To: <05fe01c89a51$f544bb90$0600a8c0@china.huawei.com> Subject: Re: [Isms] What granularity of attributes do we need for the secure transport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org David Harrington writes... > If RADIUS will specify requirements for the service, we MUST be able > to verify we do meet the requirements. Yes. It need not be done within the SNMP engine and, for the reasons you have described, that's not a likely place for this enforcement to exist. I would think the likely place would be in the SSH server at the NAS. It could also exist in the RADIUS server, based on suitable "hint" attributes. I think that is a user configuration choice, however, not a protocol design choice. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 9 11:21:17 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DE333A6B1C; Wed, 9 Apr 2008 11:21:17 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92BC628C2AE for ; Wed, 9 Apr 2008 11:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fp7oA2tYdJGw for ; Wed, 9 Apr 2008 11:21:09 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 5EFB928C234 for ; Wed, 9 Apr 2008 11:21:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=M6rtVsW5fpfnlUNjKp4d54Opav8dO1Q2mmQ4ne/3mQQZ3Wbln+vqSMZiyssVYrE9; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.78.232] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JjevF-0001Rw-Qs for isms@ietf.org; Wed, 09 Apr 2008 14:21:26 -0400 Message-ID: <000601c89a66$358e0260$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001a01c8999c$22b38f40$6801a8c0@oemcomputer> <20080409133928.GB16117@elstar.local> Date: Wed, 9 Apr 2008 11:21:54 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc891172e011fa183bfc67daf2c41a05a071aa6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.232 Subject: Re: [Isms] What granularity of attributes do we need for thesecuretransport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, April 09, 2008 7:39 AM > Subject: Re: [Isms] What granularity of attributes do we need for thesecuretransport? ... > Randy, can you check the text in ? > There is already text talking about this - if you think the text needs > improvement, please post suggested changes. ... You asked for it. Existing text: The SSH Transport Model has no way to verify that server authentication was performed, to learn the host's public key in advance, or verify that the correct key is being used. The SSH Transport Model simply trusts that these are properly configured by the implementer and deployer. Add: Consequently, within a management domain using this transport model, steps outside the scope of this document MUST be taken to ensure that all systems within that domain have indeed been correctly implemented, deployed, and configured, and that those configurations cannot be modified in inappropriate ways. That might be the intent of the following sections in the security considerations section, but I must admit that they leave me with the feeling of relying on "and then a miracle occurs", even with the level of detail that's there. Perhaps it's just the sheer number of assumptions. But others in this thread have articulated those issues more clearly. Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 9 14:52:19 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EDC028C255; Wed, 9 Apr 2008 14:52:19 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B07528C330 for ; Wed, 9 Apr 2008 14:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlxp8067u6xr for ; Wed, 9 Apr 2008 14:52:11 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 9C75A28C3A7 for ; Wed, 9 Apr 2008 14:51:02 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id E488239A26C for ; Wed, 9 Apr 2008 14:50:55 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:subject:organization:date:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=3XcX5t0gGrzuOzrE9TEfihfrxhY=; b=HXbsST1+17FmF6RIdHb6DNTzdeVqoXLXpqQzRA3Nf/LoR27wDz5sGK4e8x6+3Df2JFR8Fr+iUv/5GfuPwWRTESJQhaj20xcgRSzqsNW2jhGNFb+bkQEM6jFbV/SIn/V+SDgBKtTi2Rwrv9pEenWH3msyUc/KoTj+pjtI9VKt+ck= Received: by wes.hardakers.net (Postfix, from userid 274) id BF8E439A26D; Wed, 9 Apr 2008 14:50:55 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Wed, 09 Apr 2008 14:50:55 -0700 Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Subject: [Isms] review of draft-ietf-isms-radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I've read the -02 version of the radius usage draft and think it's a well written, nicely terse and very understandable document. I have a few nits and a few issues with it but other than that think it should go forward. Even though this is a bit late, Jurgen assured me the write up would still be appreciated. Hopefully the "issues" are understandable. Let me know if they're not and I'll elaborate with greater details or examples. ======================================== Issues: 2.0 paragraph 5 (mostly the last sentence): One reason that RADIUS-provisioned service authorization is important is that in many deployments the RADIUS server's back-end authentication database contains credentials for many classes of users, only a small portion of which may be authorized to access the management interfaces of managed entities (NASes) via SNMP. In the absence of RADIUS-provisioned service authorization, network management access may be granted to unauthorized, but properly authenticated, users. This is not correct at all (and would be really bad from a security perspective if it was true). If RADIUS didn't provision service authorization then network management access would not be granted at all if there was no other provisioning (like in place priory configuration). That last sentence implies that without RADIUS access would magically be granted to users or that if RADIUS provided authentication but did not provide authorization then access would magically get granted to users, which isn't true. Even if a non-SNMP user was properly authenticated to a device over an SNMP transport authenticating through RADIUS, the user still wouldn't be able to actually do anything without proper VACM configuration in place to allow it to happen. (Traps and informs are a more interesting case, but the IETF has yet to standardize trap and inform acceptance and action authorization.) ---------------------------------------- Section 5: Security Considerations: No where in this section does it discuss the ramifications of relying on a centralized network based authentication system. Looking very quickly (but not in detail so I may have missed it) at the other documents that this section references, it doesn't look like they do either. SNMP has traditionally designed to be used in a way that makes it always available if you can get to the device in question. The use of RADIUS changes this and adds additional dependencies on network availability. It will now possible to perform new denial of service attacks by attacking the infrastructure between the SNMP server using RADIUS for authentication and the RADIUS server providing that authentication back-end. The use is certainly well justified as RADIUS will provide many positive benefits that may be worth the cost, but the downsides should still be documented. -------------------- Section 5 paragraphs 3: Note that if the SNMP Message Processing Module selects the SNMPv1 or SNMPv2c Security Model as the security model to use (because the message is SNMPv1 or SNMPv2), then securityName comes from the community name, as per RFC3584. This may not be what is expected when using an SNMP secure Transport Model. The problem is if we start attaching RADIUS authorization fields to the Access-Accept message then we need to ensure that the authorization is only granted to the securityName the RADIUS protocol expects it to be granted to. EG, if RADIUS decides that user Wes should be allowed to access the SNMP service using authPriv over his SSH session but should be restricted to read-only access (which I realize this draft doesn't discuss and is a topic of future research), then if Wes specifies a community name that is allowed write access via the existing VACM/COMMUNITY config then Wes is being granted access beyond what was negotiated. The real problem, and this is what I think should be documented as the above only really applies to future work, is that if RADIUS and a secure transport (eg SSH) was used to authenticate and protect a message and if the v1/v2c community security model was selected then configuration would have to exist that allowed those community names to come in over unsecured transport. Restated: the community name would need to be given rights in the VACM and COMMUNITY MIBs that would allow it to be used regardless of whether it came in over the secure transport or not (since the MIBs don't have a flag for 'only if over SSH, DTLS or similar'). Thus I'd add something like: It is NOT RECOMMENDED that a combination of a secure transport, RADIUS authentication and the SNMPv1 and/or SNMPv2c community models be used since it necessitates the opening of an insecure access pass within the ACS. IE, people may think they've secured their v1/v2c deployment or implementation by using SSH but in fact it may open an additional access hole regardless of whether they use that access method themselves. -------------------- Section 6 paragraph 4: Similar problem with USM as well... noAuthNoPriv user names within a USM based message will result in the VACM being configured to allow access from a noAuthNoPriv user which would then be accessible outside the secure transport that was used. At least with authNoPriv the USM user has been authenticated using a secure authentication system (HMAC MD5 or SHA1) along with the RADIUS authentication but the message would still be protected with less encryption than was expected by the secure transport/RADIUS negotiated half of the system. ======================================== Nits/Edits: 1.1, paragraph 2: OLD: protocols, since the other network management interfaces such as NETCONF are capable of authentication with the same RADIUS server. NEW: (delete the) protocols, since other network management interfaces such as NETCONF may be capable of authentication with the same RADIUS server. -------------------- 1.1, paragraph 3: While it is customary in SNMP documents to indicate which subsystem performs specific processing tasks, in this document we leave such decisions to the implementer, as is customary for RADIUS documents, and simply specify NAS behavior. COMMENT: I'd suggest making this two sentences for better readability -------------------- 1.2, paragraph 3: This is just avoid generalizing as to popularity of deployment types: OLD: Access-Accept messages are typically populated with one or more NEW: Access-Accept messages are populated with zero or more -------------------- 1.3, paragraphs 3 and 4: Secure transport protocols do not, however, specify how the transport interfaces to authentication clients, leaving such as implementation specific. For e.g., the "password" method of SSH authentication ... This section implies that it is impossible to use RADIUS for just authorization distribution? IE, you can't use SSH public/private key pairs to do the authentication and merely use RADIUS to pull other provisioning information? (this doesn't shock me, I'm just curious). -------------------- 1.3 paragraph 3: SSH server implementations often use the Pluggable Authentication Modules (PAM) interface provided by operating systems ^ ^ It'd be good to stick an informative reference there. -------------------- 2.0 paragraph 3: Removing "in-between" text. It's either important or not so if you think it is, I'd say that: OLD: based Security Model (USM), this distinction is not significant. For the SNMP Transport Models and the SNMP Transport Security Model (TSM), this distinction is relevant, and perhaps important. NEW: based Security Model (USM), this distinction is not significant. For the SNMP Transport Models and the SNMP Transport Security Model (TSM), this distinction is relevant and important. -------------------- 2.0 paragraph 6: OLD: A detailed description of how an Access Control Model (ACM) might utilize the services of a RADIUS client to obtain access control policy information is ***the*** topic of current research, and beyond the scope of this document. NEW: A detailed description of how an Access Control Model (ACM) might utilize the services of a RADIUS client to obtain access control policy information is ***a*** topic of current research, and beyond the scope of this document. -------------------- 2.1 paragraph 1: OLD: This document will rely ***of*** implementation specific integration of the transport protocols with RADIUS clients for user authentication. NEW: This document will rely ***on*** implementation specific integration of the transport protocols with RADIUS clients for user authentication. -------------------- 2.3: This whole section discusses two different cases: RADIUS:Integrity-Confidentiality-Protection and mapping to SNMP:authPriv and RADIUS:No-Protection and its mapping to SNMP:noAuthNoPriv. But it never mentions whether RADIUS:Integrity-Protection exists (I'm guessing at a name here; I'm not a RADIUS expert) and whether it can map to SNMP:authNoPriv. Is it possible to do an authNoPriv equivalent? Either way, it should be discussed. -------------------- 2.4: OLD: (VACM) [RFC3415], might utilize RADIUS authorization are ***the*** topic of current research, and beyond the scope of this document. NEW: (VACM) [RFC3415], might utilize RADIUS authorization are ***a*** topic of current research, and beyond the scope of this document. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 11 05:58:48 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B743A69E1; Fri, 11 Apr 2008 05:58:48 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E266B3A6C97 for ; Fri, 11 Apr 2008 05:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.844 X-Spam-Level: X-Spam-Status: No, score=-0.844 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na3s-dD4Hrza for ; Fri, 11 Apr 2008 05:58:43 -0700 (PDT) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 4BE1E3A6A55 for ; Fri, 11 Apr 2008 05:58:43 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id CBJy1Z0010vp7WLA30Ap00; Fri, 11 Apr 2008 12:56:39 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id CCz31Z00924Kx1C8R00000; Fri, 11 Apr 2008 12:59:05 +0000 X-Authority-Analysis: v=1.0 c=1 a=L7yJt5vnWwKc_ra47L4A:9 a=FixS_eXZlMqY8Fo0F-em6Uhguk0A:4 a=5FtdkfQUxfIA:10 From: "David B. Nelson" To: "'Wes Hardaker'" References: Date: Fri, 11 Apr 2008 08:59:12 -0400 Message-ID: <026901c89bd3$d7a5c830$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciajBd5STWaQ/E/Q3akwcZ27X2JbQBR2ctg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Cc: isms@ietf.org Subject: Re: [Isms] review of draft-ietf-isms-radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Wes, Thank you very much for your review. I really appreciate it. I've been ignoring it up to now, solely because I've had very little time for IETF work this week. I hope to circle back and address your comments sometime next week. Regards, Dave _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 11 08:50:58 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 041473A6F48; Fri, 11 Apr 2008 08:50:58 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2CC3A6E37 for ; Fri, 11 Apr 2008 08:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tm45DbF3slmV for ; Fri, 11 Apr 2008 08:50:54 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 01D463A6F56 for ; Fri, 11 Apr 2008 08:50:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,642,1199692800"; d="scan'208";a="21122749" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 11 Apr 2008 08:51:05 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3BFp5pw029734; Fri, 11 Apr 2008 08:51:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3BFp5bd028488; Fri, 11 Apr 2008 15:51:05 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Apr 2008 08:51:05 -0700 Received: from 10.21.118.80 ([10.21.118.80]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 Apr 2008 15:50:30 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 11 Apr 2008 08:50:28 -0700 From: Kaushik Narayan To: Wes Hardaker , Message-ID: Thread-Topic: [Isms] review of draft-ietf-isms-radius-usage Thread-Index: Acib68OFAlfhhQffEd2nwgAX8tamGQ== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 11 Apr 2008 15:51:05.0347 (UTC) FILETIME=[D9C86D30:01C89BEB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11634; t=1207929065; x=1208793065; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20Kaushik=20Narayan=20 |Subject:=20Re=3A=20[Isms]=20review=20of=20draft-ietf-isms- radius-usage |Sender:=20; bh=Jk8i/mNrmcZsqBw7zigZQCDc/8NUtdVbtcJj4ZXG/A8=; b=Vs+gGzMl+UMUixm+3uVXYpScv8vXmRUK4w4B7iYV7ze6ZgobNQoYhgVHF6 YsEcQPr+1CZV3Q9TuWP0L9bNEDiFQYx+myqyjqijwkpLyULNij7GHkv57F4Q jjUCgwrHftTSIrXz4lbuuOOlVHH4mqBLdUvpkqatpZmgv/6StVIn0=; Authentication-Results: sj-dkim-1; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Isms] review of draft-ietf-isms-radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi Wes, Thanks for your comments. Please find my response inline. On 4/9/08 2:50 PM, "Wes Hardaker" wrote: > > I've read the -02 version of the radius usage draft and think it's a > well written, nicely terse and very understandable document. I have a > few nits and a few issues with it but other than that think it should go > forward. > > Even though this is a bit late, Jurgen assured me the write up would > still be appreciated. Hopefully the "issues" are understandable. Let > me know if they're not and I'll elaborate with greater details or examples. > > ======================================== Issues: > > 2.0 paragraph 5 (mostly the last sentence): > > One reason that RADIUS-provisioned service authorization is important > is that in many deployments the RADIUS server's back-end > authentication database contains credentials for many classes of > users, only a small portion of which may be authorized to access the > management interfaces of managed entities (NASes) via SNMP. In the > absence of RADIUS-provisioned service authorization, network > management access may be granted to unauthorized, but properly > authenticated, users. > > This is not correct at all (and would be really bad from a security > perspective if it was true). If RADIUS didn't provision service > authorization then network management access would not be granted at all > if there was no other provisioning (like in place priory configuration). > > That last sentence implies that without RADIUS access would magically be > granted to users or that if RADIUS provided authentication but did not > provide authorization then access would magically get granted to users, > which isn't true. Even if a non-SNMP user was properly authenticated to > a device over an SNMP transport authenticating through RADIUS, the user > still wouldn't be able to actually do anything without proper VACM > configuration in place to allow it to happen. > > (Traps and informs are a more interesting case, but the IETF has yet to > standardize trap and inform acceptance and action authorization.) You are right. Service authorization is a coarse granular mechanism to limit SNMP access only to operators/admins and deny access to a large population of users that may be authenticated by the RADIUS server. As you point out, lack of service authorization will require administrators to setup VACM and it is not a security issue but it provides ease of management. We will update the text in this section > > ---------------------------------------- > > Section 5: Security Considerations: > > No where in this section does it discuss the ramifications of relying on > a centralized network based authentication system. Looking very quickly > (but not in detail so I may have missed it) at the other documents that > this section references, it doesn't look like they do either. SNMP has > traditionally designed to be used in a way that makes it always > available if you can get to the device in question. The use of RADIUS > changes this and adds additional dependencies on network availability. > It will now possible to perform new denial of service attacks by > attacking the infrastructure between the SNMP server using RADIUS for > authentication and the RADIUS server providing that authentication > back-end. The use is certainly well justified as RADIUS will provide > many positive benefits that may be worth the cost, but the downsides > should still be documented. > Section 4.1 of RFC3579 discusses the threat model for RADIUS. All those threats apply to usage of RADIUS in ISMS. > -------------------- > > Section 5 paragraphs 3: > > Note that if the SNMP Message Processing Module selects the SNMPv1 or > SNMPv2c Security Model as the security model to use (because the > message is SNMPv1 or SNMPv2), then securityName comes from the > community name, as per RFC3584. This may not be what is expected > when using an SNMP secure Transport Model. > > The problem is if we start attaching RADIUS authorization fields to the > Access-Accept message then we need to ensure that the authorization is > only granted to the securityName the RADIUS protocol expects it to be > granted to. EG, if RADIUS decides that user Wes should be allowed to > access the SNMP service using authPriv over his SSH session but should > be restricted to read-only access (which I realize this draft doesn't > discuss and is a topic of future research), then if Wes specifies a > community name that is allowed write access via the existing > VACM/COMMUNITY config then Wes is being granted access beyond what was > negotiated. > > The real problem, and this is what I think should be documented as the > above only really applies to future work, is that if RADIUS and a secure > transport (eg SSH) was used to authenticate and protect a message and if > the v1/v2c community security model was selected then configuration > would have to exist that allowed those community names to come in over > unsecured transport. Restated: the community name would need to be > given rights in the VACM and COMMUNITY MIBs that would allow it to be > used regardless of whether it came in over the secure transport or not > (since the MIBs don't have a flag for 'only if over SSH, DTLS or similar'). > > Thus I'd add something like: It is NOT RECOMMENDED that a combination of > a secure transport, RADIUS authentication and the SNMPv1 and/or SNMPv2c > community models be used since it necessitates the opening of an > insecure access pass within the ACS. > > IE, people may think they've secured their v1/v2c deployment or > implementation by using SSH but in fact it may open an additional access > hole regardless of whether they use that access method themselves. > -------------------- > > Section 6 paragraph 4: > > Similar problem with USM as well... noAuthNoPriv user names within a > USM based message will result in the VACM being configured to allow > access from a noAuthNoPriv user which would then be accessible outside > the secure transport that was used. > > At least with authNoPriv the USM user has been authenticated using a > secure authentication system (HMAC MD5 or SHA1) along with the RADIUS > authentication but the message would still be protected with less > encryption than was expected by the secure transport/RADIUS negotiated > half of the system. That's a fair point. The text was meant to indicate that deployments cannot expect inter-operability between community based authentication/USM authentication with RADIUS authentication. It does not currently point out the side effect of such behavior. It will be good to clarify. We will add your suggested text to the draft. > > > ======================================== Nits/Edits: We will fix the nits. Regards, kaushik > > 1.1, paragraph 2: > > OLD: > protocols, since the other network management interfaces such as > NETCONF are capable of authentication with the same RADIUS server. > > NEW: (delete the) > protocols, since other network management interfaces such as > NETCONF may be capable of authentication with the same RADIUS server. > > > -------------------- > 1.1, paragraph 3: > While it is customary in SNMP > documents to indicate which subsystem performs specific processing > tasks, in this document we leave such decisions to the implementer, > as is customary for RADIUS documents, and simply specify NAS > behavior. > > COMMENT: I'd suggest making this two sentences for better readability > > > -------------------- > 1.2, paragraph 3: > > This is just avoid generalizing as to popularity of deployment types: > > OLD: > Access-Accept messages are typically populated with one or more > > NEW: > Access-Accept messages are populated with zero or more > > -------------------- > 1.3, paragraphs 3 and 4: > > Secure transport protocols do not, however, specify how the transport > interfaces to authentication clients, leaving such as implementation > specific. For e.g., the "password" method of SSH authentication > ... > > This section implies that it is impossible to use RADIUS for just > authorization distribution? IE, you can't use SSH public/private key > pairs to do the authentication and merely use RADIUS to pull > other provisioning information? (this doesn't shock me, I'm just > curious). > > -------------------- > 1.3 paragraph 3: > > SSH server implementations often use the Pluggable > Authentication Modules (PAM) interface provided by operating systems > ^ > ^ > > It'd be good to stick an informative reference there. > > -------------------- > > 2.0 paragraph 3: > > Removing "in-between" text. It's either important or not so if you > think it is, I'd say that: > > OLD: > based Security Model (USM), this distinction is not significant. For > the SNMP Transport Models and the SNMP Transport Security Model > (TSM), this distinction is relevant, and perhaps important. > > NEW: > based Security Model (USM), this distinction is not significant. For > the SNMP Transport Models and the SNMP Transport Security Model > (TSM), this distinction is relevant and important. > > > -------------------- > > 2.0 paragraph 6: > > OLD: > A detailed description of how an Access Control > Model (ACM) might utilize the services of a RADIUS client to obtain > access control policy information is ***the*** topic of current research, > and beyond the scope of this document. > > NEW: > A detailed description of how an Access Control > Model (ACM) might utilize the services of a RADIUS client to obtain > access control policy information is ***a*** topic of current research, > and beyond the scope of this document. > > > -------------------- > > 2.1 paragraph 1: > > OLD: > This document will rely ***of*** implementation specific integration of the > transport protocols with RADIUS clients for user authentication. > > NEW: > This document will rely ***on*** implementation specific integration of the > transport protocols with RADIUS clients for user authentication. > > -------------------- > > 2.3: > > This whole section discusses two different cases: > RADIUS:Integrity-Confidentiality-Protection and mapping to SNMP:authPriv > and RADIUS:No-Protection and its mapping to SNMP:noAuthNoPriv. But it > never mentions whether RADIUS:Integrity-Protection exists (I'm guessing > at a name here; I'm not a RADIUS expert) and whether it can map to > SNMP:authNoPriv. Is it possible to do an authNoPriv equivalent? Either > way, it should be discussed. > > -------------------- > 2.4: > > OLD: > (VACM) [RFC3415], might utilize RADIUS authorization are ***the*** topic of > current research, and beyond the scope of this document. > > NEW: > (VACM) [RFC3415], might utilize RADIUS authorization are ***a*** topic of > current research, and beyond the scope of this document. > > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 11 09:21:37 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85B343A6A51; Fri, 11 Apr 2008 09:21:37 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CC1B3A6937 for ; Fri, 11 Apr 2008 09:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wu+yR2ymx0QO for ; Fri, 11 Apr 2008 09:21:35 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 0E68E3A6D00 for ; Fri, 11 Apr 2008 09:21:34 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 1F09539A26C; Fri, 11 Apr 2008 09:21:12 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=IFObCu9FulNUjGhYdA4QpY8euCI=; b=sTNK21kBDhoF/BKeqfblPkkrqapUEQrhYCfmaJuHkNpUrtoiwbV135HC6tj62QNV2Kep9elObPTFswvzpIZyKi//Lbg53nDzR9jxXi/9/1zTAUTrZHZcazjlHAi5z8xakPWNfHwS8NR3Q6WRsnpFCXRtR8c1zH5BFBxz2QigGiQ= Received: by wes.hardakers.net (Postfix, from userid 274) id E653C2C3222; Fri, 11 Apr 2008 09:21:11 -0700 (PDT) From: Wes Hardaker To: Kaushik Narayan Organization: Sparta References: Date: Fri, 11 Apr 2008 09:21:11 -0700 In-Reply-To: (Kaushik Narayan's message of "Fri, 11 Apr 2008 08:50:28 -0700") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] review of draft-ietf-isms-radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi Kaushik, Thanks for the responses! KN> You are right. Service authorization is a coarse granular mechanism KN> to limit SNMP access only to operators/admins and deny access to a KN> large population of users that may be authenticated by the RADIUS KN> server. As you point out, lack of service authorization will require KN> administrators to setup VACM and it is not a security issue but it KN> provides ease of management. KN> We will update the text in this section Thanks. Please make sure that it's clear that the important thing is that RADIUS may propose additional restrictions, but just by using RADIUS you still need VACM configuration in place until the "future research" on distributing VACM content is completed. RADIUS may result in closing of the connection and no messages making it to the VACM layer, but it doesn't remove the VACM layer either... > No where in this section does it discuss the ramifications of relying on > a centralized network based authentication system. Looking very quickly > (but not in detail so I may have missed it) at the other documents that > this section references, it doesn't look like they do either. SNMP has > traditionally designed to be used in a way that makes it always > available if you can get to the device in question. The use of RADIUS > changes this and adds additional dependencies on network availability. > It will now possible to perform new denial of service attacks by > attacking the infrastructure between the SNMP server using RADIUS for > authentication and the RADIUS server providing that authentication > back-end. The use is certainly well justified as RADIUS will provide > many positive benefits that may be worth the cost, but the downsides > should still be documented. KN> Section 4.1 of RFC3579 discusses the threat model for RADIUS. All those KN> threats apply to usage of RADIUS in ISMS. That section doesn't discuss my concerns above. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 11 11:00:29 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE383A6CC0; Fri, 11 Apr 2008 11:00:29 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4475E28C1EB for ; Fri, 11 Apr 2008 11:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4xix0XpVpbo for ; Fri, 11 Apr 2008 11:00:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 4A40128C218 for ; Fri, 11 Apr 2008 11:00:09 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2EB1DC0042; Fri, 11 Apr 2008 20:00:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4qJ3sYEU9Vli; Fri, 11 Apr 2008 20:00:27 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E717C002D; Fri, 11 Apr 2008 20:00:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 961145314FF; Fri, 11 Apr 2008 20:00:26 +0200 (CEST) Date: Fri, 11 Apr 2008 20:00:26 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20080411180026.GA19503@elstar.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <001a01c8999c$22b38f40$6801a8c0@oemcomputer> <20080409133928.GB16117@elstar.local> <000601c89a66$358e0260$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <000601c89a66$358e0260$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: isms@ietf.org Subject: Re: [Isms] What granularity of attributes do we need for thesecuretransport? X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Wed, Apr 09, 2008 at 11:21:54AM -0600, Randy Presuhn wrote: > You asked for it. > > Existing text: > The SSH Transport Model has no way to verify that server > authentication was performed, to learn the host's public key in > advance, or verify that the correct key is being used. The SSH > Transport Model simply trusts that these are properly configured by > the implementer and deployer. > > Add: > Consequently, within a management domain using this transport > model, steps outside the scope of this document MUST be taken > to ensure that all systems within that domain have indeed been > correctly implemented, deployed, and configured, and that those > configurations cannot be modified in inappropriate ways. > > That might be the intent of the following sections in the security > considerations section, but I must admit that they leave me with the > feeling of relying on "and then a miracle occurs", even with the level > of detail that's there. Perhaps it's just the sheer number of assumptions. > But others in this thread have articulated those issues more clearly. David, can you massage something like Randy suggeste this into the security considerations text? /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 11 14:20:48 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F413A6AE7; Fri, 11 Apr 2008 14:20:48 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005053A6AE7 for ; Fri, 11 Apr 2008 14:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3itf9YATjd8P for ; Fri, 11 Apr 2008 14:20:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B1F453A693A for ; Fri, 11 Apr 2008 14:20:46 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19A14C003A; Fri, 11 Apr 2008 23:21:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jYR0DFd22neD; Fri, 11 Apr 2008 23:20:02 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 580C0C0042; Fri, 11 Apr 2008 23:21:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F246F531AB6; Fri, 11 Apr 2008 23:21:03 +0200 (CEST) Date: Fri, 11 Apr 2008 23:21:03 +0200 From: Juergen Schoenwaelder To: David B Harrington Message-ID: <20080411212103.GA19771@elstar.local> Mail-Followup-To: David B Harrington , isms@ietf.org References: <20080327212832.GB4281@elstar.local> <00ad01c89359$0f336ce0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <00ad01c89359$0f336ce0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: isms@ietf.org Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Mon, Mar 31, 2008 at 02:00:09PM -0400, David B Harrington wrote: > #2 could be resolved by allowing an operator to preconfigure a MIB > like usmUserTable to provide the mapping from various > mechanism-specific identities to securityName. Such preconfiguration > could use the identity function to set secruityName if no mapping is > provided. Or, they could preconfigure in an implementation-dependent > manner. Without preconfiguration, and using a default identity > function, an operator would need a VACM entry for each > mechanism-specific identity. Jeffrey Hutzelman clarified in January that SSH always provides you with an authenticated user name, regardless which SSH authentication mechanism is used. So it seems we do not need a mapping mechanism, at least not for the sake of hiding details for different authentication mechanisms. Can you go back to Jeff's message and see wether that changes your mind? Or alternatively, can you explain why such a mapping is still needed (in the simple case #2)? > #3 (same as #2; opposite direction. Not sure if there are any > additional complications in this direction. This case is less well understood so I am not sure if in the opposite direction a mapping would make things simpler. > #5 and #8 can be resolved by having securityModel in tmStateRef > override message processing selection of model. But we would need to > discuss security considerations for doing so, and check whether there > are any unforeseen implications (much as doing it the current way had > implications with RFC3584). If we do this, then #2 and #3 > preconfiguration might become specific to each transport mapping, or > share a common table. I am not sure we want this "global override". While doing this override for SNMPv1/SNMPv2c might make sense, I believe it is a feature to be able to replace the TSM in case we figure out something better is needed. I like the flexibility the current architecture allows. While SNMPv3/USM/SSH may not make much sense, I consider it a feature that it would actually work and who knows whether we ever need SNMPv3/XXX/SSH. An update of RFC3584 seems to be out of scope for this WG. I suggest that people interested in updating RFC3584 work out the details on an individual draft and then we can ask ADs for advice where such work could fit in (e.g. the OPSAWG) and see whether there is support for such work. We have to focus on making SNMPv3 run over SSH. > #6 is about whether the access controls applied are for the same > authenticated identity (client vs server) as in USM. I think this > needs further research of who must be authenticated for each operation > type, and whether the security rules about which identity must be > authenticated when using an operation are consistent with SSH and USM > and the architecture. How can we make progress on this? Would a conference call help? We have gone through this before; perhaps we need to revisit the options we have and come up with pro/con criterias to select one. /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 11 14:56:38 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4442E3A6AC5; Fri, 11 Apr 2008 14:56:38 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC513A6B05 for ; Fri, 11 Apr 2008 14:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+Mmy+FsJ4XP for ; Fri, 11 Apr 2008 14:56:36 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 8BB533A6984 for ; Fri, 11 Apr 2008 14:56:36 -0700 (PDT) Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m3BLurDu001496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2008 17:56:53 -0400 (EDT) Date: Fri, 11 Apr 2008 17:56:53 -0400 From: Jeffrey Hutzelman To: j.schoenwaelder@jacobs-university.de, David B Harrington Message-ID: <18DE9A9BBD7CE0C3139F4528@sirius.fac.cs.cmu.edu> In-Reply-To: <20080411212103.GA19771@elstar.local> References: <20080327212832.GB4281@elstar.local> <00ad01c89359$0f336ce0$0600a8c0@china.huawei.com> <20080411212103.GA19771@elstar.local> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Disposition: inline Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org --On Friday, April 11, 2008 11:21:03 PM +0200 Juergen Schoenwaelder wrote: >> # 5 and #8 can be resolved by having securityModel in tmStateRef >> override message processing selection of model. But we would need to >> discuss security considerations for doing so, and check whether there >> are any unforeseen implications (much as doing it the current way had >> implications with RFC3584). If we do this, then #2 and #3 >> preconfiguration might become specific to each transport mapping, or >> share a common table. > > I am not sure we want this "global override". While doing this override > for SNMPv1/SNMPv2c might make sense, I believe it is a feature to be > able to replace the TSM in case we figure out something better is > needed. I like the flexibility the current architecture allows. While > SNMPv3/USM/SSH may not make much sense, I consider it a feature that > it would actually work and who knows whether we ever need > SNMPv3/XXX/SSH. I agree. I don't see a major problem with allowing securityModel in tmStateRef to control when the MPM does not provide a way of carrying securityModel, as is the case with SNMPv1/SNMPv2c, but if the MPM does provide have that capability, as SNMPv3 does, it should be obeyed. To contrive an example where it might matter... Suppose instead of SSHTM+TSM, we had defined TLSTM+TSM, where TLSTM provides authentication using client certificates. This new transport model would indicate use of TSM by setting securityModel in tmStateRef, exactly as SSHTM would today. Now, someone might come along and provide a new GSS-API security model (GSM), which allows use of an arbitrary GSS-API mechanism to authenticate the user, and then uses channel bindings to tie that authentication to the channel provided by the underlying transport model. Having defined this new model, we now want to use SNMPv3/GSM/TLSTM, binding the GSS-API authentication to the channel provided by TLS. This is possible with the architecture as we have defined it, but would break if TLSTM's assertion that TSM is to be used is allowed to override the securityModel carried by SNMPv3 which indicates that GSM should be used. Let's avoid this whole mess by defining the override behavior _only_ for SNMPv1/SNMPv2c. -- Jeff _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 11 15:11:12 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1529E3A6B7F; Fri, 11 Apr 2008 15:11:12 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C3C3A68D3 for ; Fri, 11 Apr 2008 15:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQ80-acPyqpq for ; Fri, 11 Apr 2008 15:11:09 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id F2E873A6B72 for ; Fri, 11 Apr 2008 15:10:44 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA09.westchester.pa.mail.comcast.net with comcast id CM2T1Z00y0vyq2s5902p00; Fri, 11 Apr 2008 22:09:17 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA05.westchester.pa.mail.comcast.net with comcast id CNB41Z0074HwxpC3R00000; Fri, 11 Apr 2008 22:11:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=su7bgufOh_4Dm17nsK8A:9 a=RB_z3iShgts6y71ChtMA:7 a=PHvRYQ_geMYb0Q3H8vzfiSkIMPcA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Jeffrey Hutzelman'" , References: <20080327212832.GB4281@elstar.local> <00ad01c89359$0f336ce0$0600a8c0@china.huawei.com> <20080411212103.GA19771@elstar.local> <18DE9A9BBD7CE0C3139F4528@sirius.fac.cs.cmu.edu> Date: Fri, 11 Apr 2008 18:11:04 -0400 Message-ID: <007301c89c20$ef7e2f90$6502a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <18DE9A9BBD7CE0C3139F4528@sirius.fac.cs.cmu.edu> thread-index: AcicHvfGbM+GMN1nT/OBqkVzSTfZ2AAASwoA Cc: isms@ietf.org Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, For incoming messages, the transport model has no idea which message version is being used. The transport model only forwards the wholeMessage as received from the network (e.g. passed by SSH). Determining which message version does not happen until the Message Processing Subsystem decodes the message version from the ASN.1 format, and then passes the wholeMessage to the appropriate message processing model for processing. The transport subsystem should not care which mesage version is being carried. dbh > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] > Sent: Friday, April 11, 2008 5:57 PM > To: j.schoenwaelder@jacobs-university.de; David B Harrington > Cc: isms@ietf.org; jhutz@cmu.edu > Subject: Re: [Isms] open issues > > --On Friday, April 11, 2008 11:21:03 PM +0200 Juergen Schoenwaelder > wrote: > > >> # 5 and #8 can be resolved by having securityModel in tmStateRef > >> override message processing selection of model. But we > would need to > >> discuss security considerations for doing so, and check > whether there > >> are any unforeseen implications (much as doing it the > current way had > >> implications with RFC3584). If we do this, then #2 and #3 > >> preconfiguration might become specific to each transport > mapping, or > >> share a common table. > > > > I am not sure we want this "global override". While doing > this override > > for SNMPv1/SNMPv2c might make sense, I believe it is a feature to be > > able to replace the TSM in case we figure out something better is > > needed. I like the flexibility the current architecture > allows. While > > SNMPv3/USM/SSH may not make much sense, I consider it a feature that > > it would actually work and who knows whether we ever need > > SNMPv3/XXX/SSH. > > I agree. I don't see a major problem with allowing securityModel in > tmStateRef to control when the MPM does not provide a way of carrying > securityModel, as is the case with SNMPv1/SNMPv2c, but if the > MPM does > provide have that capability, as SNMPv3 does, it should be obeyed. > > To contrive an example where it might matter... > > Suppose instead of SSHTM+TSM, we had defined TLSTM+TSM, where TLSTM > provides authentication using client certificates. This new > transport > model would indicate use of TSM by setting securityModel in > tmStateRef, > exactly as SSHTM would today. > > > Now, someone might come along and provide a new GSS-API > security model > (GSM), which allows use of an arbitrary GSS-API mechanism to > authenticate > the user, and then uses channel bindings to tie that > authentication to the > channel provided by the underlying transport model. Having > defined this > new model, we now want to use SNMPv3/GSM/TLSTM, binding the GSS-API > authentication to the channel provided by TLS. This is > possible with the > architecture as we have defined it, but would break if > TLSTM's assertion > that TSM is to be used is allowed to override the > securityModel carried by > SNMPv3 which indicates that GSM should be used. > > Let's avoid this whole mess by defining the override behavior > _only_ for > SNMPv1/SNMPv2c. > > -- Jeff > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 11 15:22:10 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB1B28C0FD; Fri, 11 Apr 2008 15:22:10 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C90A28C0FD for ; Fri, 11 Apr 2008 15:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wz-wIDvKFqpj for ; Fri, 11 Apr 2008 15:22:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 73F1A28C0F9 for ; Fri, 11 Apr 2008 15:22:08 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2008 15:22:32 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3BMMWh6006566; Fri, 11 Apr 2008 15:22:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3BMMWxS011404; Fri, 11 Apr 2008 22:22:32 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Apr 2008 15:22:32 -0700 Received: from 171.69.75.173 ([171.69.75.173]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 Apr 2008 22:21:43 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 11 Apr 2008 15:21:43 -0700 From: Kaushik Narayan To: Wes Hardaker Message-ID: Thread-Topic: [Isms] review of draft-ietf-isms-radius-usage Thread-Index: AcicImu2qis6TggVEd2nwgAX8tamGQ== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 11 Apr 2008 22:22:32.0323 (UTC) FILETIME=[891C8D30:01C89C22] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2592; t=1207952552; x=1208816552; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20Kaushik=20Narayan=20 |Subject:=20Re=3A=20[Isms]=20review=20of=20draft-ietf-isms- radius-usage |Sender:=20; bh=YCRD1eBeOEk4ls9sEjI55Dn5clO/O94OwT+UqkNMyd4=; b=jIjou7V8F6xewFRc6tATzm7GQmbvTxjzpryj6KXgS5kLcV1frBpU/o0aLL iyKKUh6Sug4Fp/HZO7bGq2Mhk9x8aqpea6o2i8A5+Gr3ZdnNYJxteKq5iMXD aFX3VA21wfhBNLaZeNg8oll3Nh/Ic9kHLUT8eWhrIeKtkUgffm4dI=; Authentication-Results: sj-dkim-1; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: isms@ietf.org Subject: Re: [Isms] review of draft-ietf-isms-radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi Wes, Please find my response inline. > > KN> You are right. Service authorization is a coarse granular mechanism > KN> to limit SNMP access only to operators/admins and deny access to a > KN> large population of users that may be authenticated by the RADIUS > KN> server. As you point out, lack of service authorization will require > KN> administrators to setup VACM and it is not a security issue but it > KN> provides ease of management. > > KN> We will update the text in this section > > Thanks. Please make sure that it's clear that the important thing is > that RADIUS may propose additional restrictions, but just by using > RADIUS you still need VACM configuration in place until the "future > research" on distributing VACM content is completed. RADIUS may result > in closing of the connection and no messages making it to the VACM > layer, but it doesn't remove the VACM layer either... > Sure. >> No where in this section does it discuss the ramifications of relying on >> a centralized network based authentication system. Looking very quickly >> (but not in detail so I may have missed it) at the other documents that >> this section references, it doesn't look like they do either. SNMP has >> traditionally designed to be used in a way that makes it always >> available if you can get to the device in question. The use of RADIUS >> changes this and adds additional dependencies on network availability. >> It will now possible to perform new denial of service attacks by >> attacking the infrastructure between the SNMP server using RADIUS for >> authentication and the RADIUS server providing that authentication >> back-end. The use is certainly well justified as RADIUS will provide >> many positive benefits that may be worth the cost, but the downsides >> should still be documented. > > KN> Section 4.1 of RFC3579 discusses the threat model for RADIUS. All those > KN> threats apply to usage of RADIUS in ISMS. > > That section doesn't discuss my concerns above. I guess you are referring specifically to security considerations of any form of external authentication for SNMP usage above and beyond the security issues of specific authentication protocol (RADIUS). We will add text to highlight security considerations for SNMP messages being authenticated over the network. Are there specific considerations you believe are important to highlight above and beyond the ones you have mentioned in this note regards, kaushik _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 11 17:33:23 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4E93A6ABD; Fri, 11 Apr 2008 17:33:23 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840BE3A6ABD for ; Fri, 11 Apr 2008 17:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kz97UtvxKrpo for ; Fri, 11 Apr 2008 17:33:21 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id CE9D03A6AA7 for ; Fri, 11 Apr 2008 17:33:21 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 2913639A26C; Fri, 11 Apr 2008 17:32:53 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=SXr8aU5Tx8p9epydGRcIwQ35ktE=; b=LgO9POLaSn7CtcmhIAmnX0+ZIQrmry+8jloxJEp95/4GeGGoaBwSLQxjw4RHREJ2g0Z3rRS/+Ibdl6U8uXChj6Rk6FIbeuKEZeWxDUzObWd+aQYhIoEfX4Rv+N3OtMgpTrWnMgKfDVkSDpT0ddIpet3y5Zn5P+oTh3QsUNufqTo= Received: by wes.hardakers.net (Postfix, from userid 274) id 03F6E2C3222; Fri, 11 Apr 2008 17:32:53 -0700 (PDT) From: Wes Hardaker To: Kaushik Narayan Organization: Sparta References: Date: Fri, 11 Apr 2008 17:32:52 -0700 In-Reply-To: (Kaushik Narayan's message of "Fri, 11 Apr 2008 15:21:43 -0700") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] review of draft-ietf-isms-radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> "KN" == Kaushik Narayan writes: KN> We will add text to highlight security considerations for SNMP messages KN> being authenticated over the network. Are there specific considerations you KN> believe are important to highlight above and beyond the ones you have KN> mentioned in this note Thanks! Nope, just the fact that centralized authentication has it's own issues when the protocol was originally designed to be able to fix problems when the rest of the network was inaccessible. Using a centralized server potentially adds an easy DoS attack on the entire management infrastructure as a whole because one central server can be targeted which will result in the inability to manage every device on a network. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Apr 12 05:59:54 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE5D328C219; Sat, 12 Apr 2008 05:59:54 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519CE28C1E0 for ; Sat, 12 Apr 2008 05:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Eg-YV8yntaT for ; Sat, 12 Apr 2008 05:59:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 54BCC28C167 for ; Sat, 12 Apr 2008 05:59:50 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A932C0042; Sat, 12 Apr 2008 15:00:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZyPVb+mfkLxP; Sat, 12 Apr 2008 14:58: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 4788CC003E; Sat, 12 Apr 2008 15:00:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C18E7531F96; Sat, 12 Apr 2008 15:00:09 +0200 (CEST) Date: Sat, 12 Apr 2008 15:00:09 +0200 From: Juergen Schoenwaelder To: David B Harrington Message-ID: <20080412130009.GB20150@elstar.local> Mail-Followup-To: David B Harrington , 'Jeffrey Hutzelman' , isms@ietf.org References: <20080327212832.GB4281@elstar.local> <00ad01c89359$0f336ce0$0600a8c0@china.huawei.com> <20080411212103.GA19771@elstar.local> <18DE9A9BBD7CE0C3139F4528@sirius.fac.cs.cmu.edu> <007301c89c20$ef7e2f90$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <007301c89c20$ef7e2f90$6502a8c0@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: isms@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Fri, Apr 11, 2008 at 06:11:04PM -0400, David B Harrington wrote: > For incoming messages, the transport model has no idea which message > version is being used. The transport model only forwards the > wholeMessage as received from the network (e.g. passed by SSH). > Determining which message version does not happen until the Message > Processing Subsystem decodes the message version from the ASN.1 > format, and then passes the wholeMessage to the appropriate message > processing model for processing. The transport subsystem should not > care which mesage version is being carried. The decision which security model is called is taken by the MPM; so is it not sufficient to modify the community-based MPM to check the existance of a tmStateReference? /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Apr 12 07:32:46 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184CA3A6982; Sat, 12 Apr 2008 07:32:46 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED393A6B4C for ; Sat, 12 Apr 2008 07:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_00=-2.599, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dfUl5FCKcCO for ; Sat, 12 Apr 2008 07:32:43 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 46C023A6982 for ; Sat, 12 Apr 2008 07:32:43 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id CbaA1Z0030QkzPwA70BD00; Sat, 12 Apr 2008 14:31:42 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id CeZ61Z00524Kx1C8N00000; Sat, 12 Apr 2008 14:33:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=H6jWw9XJ6XIfwo-v1E8A:9 a=-scLSKjJ2Y1kZOZ5KxcA:7 a=3cvUJJ-beiqBdqg_yaDxuYEYxWgA:4 a=5FtdkfQUxfIA:10 From: "David B. Nelson" To: References: Date: Sat, 12 Apr 2008 10:33:06 -0400 Message-ID: <034901c89caa$208b1ba0$6401a8c0@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AciajBd5STWaQ/E/Q3akwcZ27X2JbQCF5GMg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Subject: Re: [Isms] review of draft-ietf-isms-radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Wes Hardaker writes... > I've read the -02 version of the radius usage draft and think it's a > well written, nicely terse and very understandable document. Thanks. > Hopefully the "issues" are understandable. I'll offer my comments, in-line, below. Kaushik has already addressed most or all of these, but I'll add my two-cents. > This is not correct at all (and would be really bad from a security > perspective if it was true). I hope you are right. However, I've seen some implementations of SSH and RADIUS integrations where the SSH server ignores any authorization attributes that come from the RADIUS Access-Accept message. For example, there is no standardized way of getting this information via the PAM interface, although there are ways that can be made to work. > If RADIUS didn't provision service authorization then network management > access would not be granted at all if there was no other provisioning > (like in place priory configuration). Yes, *assuming* that the service granting entity in the NAS actually looks for the service provisioning information and acts upon it. As I say, I've seem implementations where it does not (poor implementations, IMHO). In any event, it is important to have RADIUS service provisioning attributes that are specific to NAS management, and in the specific instance of ISMS work, for access to the SNMP engine of the NAS. It's equally important that the NAS looks for and enforces these attributes as a condition of access. This all seems pretty obvious, of course. > That last sentence implies that without RADIUS access would magically be > granted to users or that if RADIUS provided authentication but did not > provide authorization then access would magically get granted to users, > which isn't true. One would *hope* it isn't true. > Even if a non-SNMP user was properly authenticated to > a device over an SNMP transport authenticating through RADIUS, the user > still wouldn't be able to actually do anything without proper VACM > configuration in place to allow it to happen. If proper VACM configuration had been configured, yes. > No where in this section does it discuss the ramifications of relying on > a centralized network based authentication system. I think I recall a discussion of this issue on the list or in a meeting early on. I think the analogy I used is how Unix workstation login often works in large organizations. Workstations often rely upon NIS (LDAP or similar) for centralized login administration but almost always have a local password file for a local root account. If the network is down, or the NIS server has moved, the administrator can use the local root password to gain access to the workstation. The same advice applies here. Configure your NAS with a local account (e.g. username and password) that bypasses the need for RADIUS authentication. Do we need to add that implementation reminder in this draft? > The problem is if we start attaching RADIUS authorization fields to the > Access-Accept message then we need to ensure that the authorization is > only granted to the securityName the RADIUS protocol expects it to be > granted to. Right. > EG, if RADIUS decides that user Wes should be allowed to access the > SNMP service using authPriv over his SSH session but should be > restricted to read-only access (which I realize this draft doesn't > discuss and is a topic of future research), then if Wes specifies a > community name that is allowed write access via the existing > VACM/COMMUNITY config then Wes is being granted access beyond what was > negotiated. Yeah, I see how that could happen. > The real problem, and this is what I think should be documented as the > above only really applies to future work, is that if RADIUS and a secure > transport (eg SSH) was used to authenticate and protect a message and if > the v1/v2c community security model was selected then configuration > would have to exist that allowed those community names to come in over > unsecured transport. Restated: the community name would need to be > given rights in the VACM and COMMUNITY MIBs that would allow it to be > used regardless of whether it came in over the secure transport or not > (since the MIBs don't have a flag for 'only if over SSH, DTLS or > similar'). > > Thus I'd add something like: It is NOT RECOMMENDED that a combination of > a secure transport, RADIUS authentication and the SNMPv1 and/or SNMPv2c > community models be used since it necessitates the opening of an > insecure access pass within the ACS. OK, good point. We can add some text to that effect. I am generally a bit concerned that the implications of extending the ISMS work, originally focused on v3, to v1 and v2c have not been completely though out. > Secure transport protocols do not, however, specify how the transport > interfaces to authentication clients, leaving such as implementation > specific. For e.g., the "password" method of SSH authentication > ... > > This section implies that it is impossible to use RADIUS for just > authorization distribution? Well, there has been an expensive discussion of that issue. The short answer is that you can use RADIUS to re-authorize, including providing a completely different authorization, based on a "binding" to a previous RADIUS authentication. This is "binding" is accomplished via the RADIUS State attribute (a cookie issued by the RADIUS server to the RADIUS client). This draft does not discuss RADIUS re-authorization, and how it might apply to the ISMS work is another topic for future research. > IE, you can't use SSH public/private key pairs to do the authentication > and merely use RADIUS to pull other provisioning information? That's correct. The initial authentication must have been via RADIUS, and probably via the same RADIUS server. > This whole section discusses two different cases: > RADIUS:Integrity-Confidentiality-Protection and mapping to SNMP:authPriv > and RADIUS:No-Protection and its mapping to SNMP:noAuthNoPriv. But it > never mentions whether RADIUS:Integrity-Protection exists (I'm guessing > at a name here; I'm not a RADIUS expert) and whether it can map to > SNMP:authNoPriv. Is it possible to do an authNoPriv equivalent? Either > way, it should be discussed. The RADIUS Management-Transport-Protection attribute describes the minimum required level of protection of the *transport*. Basically you can call for integrity protection (a cryptographic checksum) or integrity and confidentially protection (encrypted payload and cryptographic checksum) or no protection (unsigned clear text). In terms of the "auth" part of SNMP "authPriv", I always thought it stood for "authentication". When using RADIUS, which is all about authentication and authorization, the user is *always* authenticated, so the use of RADIUS with SNMP always implies "auth". The "noAuth" case just doesn't map. You could do an "authNoPriv" equivalent with the tools that RADIUS provides. Is that useful? _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Apr 12 08:06:49 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6718E3A6C65; Sat, 12 Apr 2008 08:06:49 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F683A6C65 for ; Sat, 12 Apr 2008 08:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9szdH56BzjA for ; Sat, 12 Apr 2008 08:06:47 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 484353A6BFB for ; Sat, 12 Apr 2008 08:06:47 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA07.westchester.pa.mail.comcast.net with comcast id Cd1b1Z0010mv7h05707F00; Sat, 12 Apr 2008 15:05:49 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.westchester.pa.mail.comcast.net with comcast id Cf781Z0034HwxpC3X00000; Sat, 12 Apr 2008 15:07:12 +0000 X-Authority-Analysis: v=1.0 c=1 a=j3Z76cjpAAAA:8 a=HLEnh3jk4A9ukupbtxgA:9 a=dkwoKh3rg9rWmrWjCWYA:7 a=SYWsh0wcx_e8KwYer6ZE6_HZ9x0A:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=gi0PWCVxevcA:10 From: "David B Harrington" To: References: <20080327212832.GB4281@elstar.local> <00ad01c89359$0f336ce0$0600a8c0@china.huawei.com> <20080411212103.GA19771@elstar.local> <18DE9A9BBD7CE0C3139F4528@sirius.fac.cs.cmu.edu> <007301c89c20$ef7e2f90$6502a8c0@china.huawei.com> <20080412130009.GB20150@elstar.local> Date: Sat, 12 Apr 2008 11:07:08 -0400 Message-ID: <008401c89cae$e0b6d460$6502a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <20080412130009.GB20150@elstar.local> thread-index: AcicnS90P496cCyaTK2/GWqPVOaX/wAEVWzQ Cc: isms@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org I believe that could work. That means modifying RFC3584. That would solve the problem for SNMPv1 and SNMPv2c. And if a new SNMPv4 message is ever created, it can be written to accommodate the presence or lack of tmStateReference. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Saturday, April 12, 2008 9:00 AM > To: David B Harrington > Cc: 'Jeffrey Hutzelman'; isms@ietf.org > Subject: Re: [Isms] open issues > > On Fri, Apr 11, 2008 at 06:11:04PM -0400, David B Harrington wrote: > > > For incoming messages, the transport model has no idea which message > > version is being used. The transport model only forwards the > > wholeMessage as received from the network (e.g. passed by SSH). > > Determining which message version does not happen until the Message > > Processing Subsystem decodes the message version from the ASN.1 > > format, and then passes the wholeMessage to the appropriate message > > processing model for processing. The transport subsystem should not > > care which mesage version is being carried. > > The decision which security model is called is taken by the MPM; so is > it not sufficient to modify the community-based MPM to check the > existance of a tmStateReference? > > /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Apr 21 09:35:48 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42EF23A6F26; Mon, 21 Apr 2008 09:35:48 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65603A68E4 for ; Mon, 21 Apr 2008 09:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKF9Pt+Qhh3C for ; Mon, 21 Apr 2008 09:35:47 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C29573A6F22 for ; Mon, 21 Apr 2008 09:35:46 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3LGZQi3010078; Mon, 21 Apr 2008 19:35:44 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Apr 2008 19:35:25 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Apr 2008 19:35:25 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 19:35:32 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7269CBC1@vaebe104.NOE.Nokia.com> In-Reply-To: <20080411212103.GA19771@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] open issues Thread-index: AcicG/aQoysSY1F3StS/2KSCVWQMZgHrnqSQ References: <20080327212832.GB4281@elstar.local><00ad01c89359$0f336ce0$0600a8c0@china.huawei.com> <20080411212103.GA19771@elstar.local> From: To: , X-OriginalArrivalTime: 21 Apr 2008 16:35:25.0659 (UTC) FILETIME=[B39552B0:01C8A3CD] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Juergen Schoenwaelder wrote: > > #6 is about whether the access controls applied are for the same > > authenticated identity (client vs server) as in USM. I think this > > needs further research of who must be authenticated for each > > operation type, and whether the security rules about which > > identity must be authenticated when using an operation are > > consistent with SSH and USM and the architecture. > > How can we make progress on this? Would a conference call help? We > have gone through this before; perhaps we need to revisit the options > we have and come up with pro/con criterias to select one. As I'm new to this topic, could you provide e.g. some links to the options that have been discussed before? Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Apr 22 14:04:07 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881C83A6CE9; Tue, 22 Apr 2008 14:04:07 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DDFA3A68B0 for ; Tue, 22 Apr 2008 14:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Rhg-cfRJX+M for ; Tue, 22 Apr 2008 14:04:01 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 98D0E3A69C3 for ; Tue, 22 Apr 2008 14:04:00 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 44F5EC0026; Tue, 22 Apr 2008 23:04:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0tT36IPW8vbG; Tue, 22 Apr 2008 23:03:57 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 936ABC0020; Tue, 22 Apr 2008 23:03:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 15D725444B7; Tue, 22 Apr 2008 23:03:56 +0200 (CEST) Date: Tue, 22 Apr 2008 23:03:55 +0200 From: Juergen Schoenwaelder To: "Pasi.Eronen@nokia.com" Message-ID: <20080422210355.GA12678@elstar.local> Mail-Followup-To: "Pasi.Eronen@nokia.com" , dbharrington@comcast.net, isms@ietf.org References: <20080411212103.GA19771@elstar.local> <1696498986EFEC4D9153717DA325CB7269CBC1@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1696498986EFEC4D9153717DA325CB7269CBC1@vaebe104.NOE.Nokia.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: dbharrington@comcast.net, isms@ietf.org Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Mon, Apr 21, 2008 at 07:35:32PM +0300, Pasi.Eronen@nokia.com wrote: > Juergen Schoenwaelder wrote: > > > > #6 is about whether the access controls applied are for the same > > > authenticated identity (client vs server) as in USM. I think this > > > needs further research of who must be authenticated for each > > > operation type, and whether the security rules about which > > > identity must be authenticated when using an operation are > > > consistent with SSH and USM and the architecture. > > > > How can we make progress on this? Would a conference call help? We > > have gone through this before; perhaps we need to revisit the options > > we have and come up with pro/con criterias to select one. > > As I'm new to this topic, could you provide e.g. some links to the > options that have been discussed before? Let me try to summarize what I think is our main problem. A traditional SNMP agent has two "modes" of operation: a) Management applications can query agents or modify state of an agent. b) An agent can generate notifications in order to asynchronously notify a manager that a certain event has happened. For the rest of the discussion, it is only important to remember that a) implies that the manager is taking the initiative and b) implies that the agent is taking the initiative. Once we talk about SSH as a secure transport for SNMP, "mode" (a) implies the manager is becoming an SSH client initiating a connection to the agent, acting as an SSH server, while "mode" (b) implies that the agent initiates a connection to the manager, acting as an SSH server. The SNMP architecture includes an access control subsystem which resides on the agent and which is called whenever information is communicated to the outside world. In "mode" a), all attempts to read/write information have to pass the access control subsystem. In "mode" b), all outgoing notifications have to pass the access control subsystem as well. The idea is ensure that a principal can only get access to the information he is authorized to receive, regardless whether the information is read, written, or communicated via a notification. Our problem now is that SSH authentication is asymmetric - the SSH client authenticates the SSH server while the SSH server authenticates an SSH user identity residing on the SSH client. As a consequence, in "mode" a) the agent has an authenticated SSH user name to base its access control decision on while in "mode" b), the agent has an authenticated host identity to base its access control decision on. It may be important to note that on a given host, there can be multiple notification receivers with different access control requirements. Several options were investigated how to address this issue and so far we have not found one that is really making people happy. Some options considered: A) A notification originator may initiates the underlying TCP connection but then the roles are swapped before the SSH exchange beginns. This "solution" has security problems and does not work. B) Notifications always travel over an SSH connection that has been initiated by a "manager" application, so we always have an authenticated user identity for access control to work as expected. If there is no suitable SSH connection, one can either revert to SNMPv3/USM (means ISMS looses its value since you still need a fully configured SNMPv3/USM infrastructure) or one can use an unauthenticated notification to let the manager initiate a suitable SSH connection (ugly and likely has similar security issues like A). Furthermore, in many implementations, command generators and notification receivers are not really tight together so using a shared SSH connection may simply not be realistic for a large range of existing code bases. C) Work around the issue by using SSH host-based authentication. This option has issues with situations where a single host may contain multiple notification receivers that are authorized to receive only different subsets of notifications, see above. There might be more options or variations we have considered and which I have forgotton to mention in this email. Was this explanation understandable? If not, keep asking questions. /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Apr 22 14:20:11 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881373A6EA1; Tue, 22 Apr 2008 14:20:11 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D713A6EA7 for ; Tue, 22 Apr 2008 14:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=1.137, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 168df2D8phoM for ; Tue, 22 Apr 2008 14:20:09 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 750193A6E33 for ; Tue, 22 Apr 2008 14:20:09 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 859452F2EEB; Tue, 22 Apr 2008 14:17:43 -0700 (PDT) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=0PCRDDCzuoo6z3cF7joiY4F7XwI=; b=kC936ArG53PLjGhzGfR8YCwGqF6odXBFTryaVcCbemg5fqNx0NeAv9jOpaKvoMyBobhx3zdlmq70QAf+2arKmNijmUxvAtVUBzgOZU8dcYUNyRh+hk9/czFrmKO+t2zGt5oRgLNbNunOLtLlbTWwEkEj+DNC7YfWLcQLDa6fvIc= Received: by wes.hardakers.net (Postfix, from userid 274) id 433BC2F2EE2; Tue, 22 Apr 2008 14:17:43 -0700 (PDT) From: Wes Hardaker To: "David B. Nelson" Organization: Sparta References: <034901c89caa$208b1ba0$6401a8c0@NEWTON603> Date: Tue, 22 Apr 2008 14:17:43 -0700 In-Reply-To: <034901c89caa$208b1ba0$6401a8c0@NEWTON603> (David B. Nelson's message of "Sat, 12 Apr 2008 10:33:06 -0400") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: isms@ietf.org Subject: Re: [Isms] review of draft-ietf-isms-radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org >>>>> On Sat, 12 Apr 2008 10:33:06 -0400, "David B. Nelson" said: David, Sorry for the delay in a response... [Re: section 2, paragraph 5 about in absence of radius distributed authorization network management access is granted] >> This is not correct at all (and would be really bad from a security >> perspective if it was true). DBN> I hope you are right. However, I've seen some implementations of SSH and DBN> RADIUS integrations where the SSH server ignores any authorization DBN> attributes that come from the RADIUS Access-Accept message. For example, DBN> there is no standardized way of getting this information via the PAM DBN> interface, although there are ways that can be made to work. It's true, of course, that there are non-compliant implementations of just about every protocol. We can't force compliance. We can only state what it means to be compliant. If the SSH/Radius standard says that you can't ignore the distributed authorization information and an implementation does so anyway, then it's not compliant. That being said, we have to write standards based on what the real world is expected to implement. If the current largest body of usable authentication plugins (PAM) means it's almost impossible to implement authorization in that manner then either PAM needs to be rewritten (UGH) or maybe the standard shouldn't have been defined that way. But this is slightly off the topic that I was trying to get at. Lets say that the SNMP/SSH/Radius combination specified that the authorization information can't be ignored in a radius packet. If an implementation choose to ignore it anyway because of implementation complexities (PAM or otherwise) they *still* wouldn't be granted access to the network management infrastructure because the SNMP/VACM combination wouldn't let them in anyway. That's not at all what the paragraph implies, which was my compliant. I believe this is going to be changed in the next rev so really I'm just adding yet more explanation in case there is still any doubt of the content from my original message. >> If RADIUS didn't provision service authorization then network management >> access would not be granted at all if there was no other provisioning >> (like in place priory configuration). DBN> Yes, *assuming* that the service granting entity in the NAS actually looks DBN> for the service provisioning information and acts upon it. As I say, I've DBN> seem implementations where it does not (poor implementations, DBN> IMHO). No, the SNMP stack would have to look at the VACM configuration regardless. If it wasn't there, it would be miscompliant with the SNMP protocol entirely (forget Radius here). Radius may provide a way to distribute that VACM config so it's not missing (future work) or could augment the VACM by stating that the only accessible path is over a transport with certain properties (and that may be ignored, you're right). >> That last sentence implies that without RADIUS access would magically be >> granted to users or that if RADIUS provided authentication but did not >> provide authorization then access would magically get granted to users, >> which isn't true. DBN> One would *hope* it isn't true. I know of no SNMPv3 compliant stack that doesn't check VACM authorization. When SNMP/SSH/Radius comes out in a stack I could see the resulting implementation ignoring the Radius set provisioning, but if it did so and it didn't have any VACM configuration already in place the packet would get no where (unless in the process of implementing the Radius part they actually removed the VACM support, which I don't see as likely). >> No where in this section does it discuss the ramifications of relying on >> a centralized network based authentication system. DBN> I think I recall a discussion of this issue on the list or in a DBN> meeting early on. I think the analogy I used is how Unix DBN> workstation login often works in large organizations. Workstations DBN> often rely upon NIS (LDAP or similar) for centralized login DBN> administration but almost always have a local password file for a DBN> local root account. If the network is down, or the NIS server has DBN> moved, the administrator can use the local root password to gain DBN> access to the workstation. A perfect analogy. But the current draft doesn't discuss such a situation nor does it recommend that to avoid it a secondary path to the SNMP infrastructure (like SNMPv3/USM without Radius) should be configured. DBN> The same advice applies here. Configure your NAS with a local DBN> account (e.g. username and password) that bypasses the need for DBN> RADIUS authentication. Do we need to add that implementation DBN> reminder in this draft? IMHO, Yes. DBN> OK, good point. We can add some text to that effect. I am generally a bit DBN> concerned that the implications of extending the ISMS work, originally DBN> focused on v3, to v1 and v2c have not been completely though out. For reference, I too think it's a bit odd and am not sure why it's so important to support. From a pure theory point of view, I can understand it. From a "is it really useful to waste that much time on" I'm less convinced that it's worth the time because it's not that needed in practice. >> This whole section discusses two different cases: >> RADIUS:Integrity-Confidentiality-Protection and mapping to SNMP:authPriv >> and RADIUS:No-Protection and its mapping to SNMP:noAuthNoPriv. ... DBN> In terms of the "auth" part of SNMP "authPriv", I always thought it stood DBN> for "authentication". When using RADIUS, which is all about authentication DBN> and authorization, the user is *always* authenticated, so the use of RADIUS DBN> with SNMP always implies "auth". The "noAuth" case just doesn't map. Ah... I'd spell that out a bit more clearly. I missed that somehow. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Apr 22 18:52:56 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2843A6E42; Tue, 22 Apr 2008 18:52:56 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4347F28C1D5 for ; Tue, 22 Apr 2008 18:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3rWZQkfh3Oq for ; Tue, 22 Apr 2008 18:52:55 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id EA6E63A6E42 for ; Tue, 22 Apr 2008 18:52:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=oxKq/N1GhPhokwpVjKF+ncE6MwUIB9I2muH0vuRmZ1dt0QrUUkYnhS7xRbtnI4eN; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.38.102] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JoUAO-0007C8-DP for isms@ietf.org; Tue, 22 Apr 2008 21:53:00 -0400 Message-ID: <002401c8a4dc$869f3400$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080411212103.GA19771@elstar.local><1696498986EFEC4D9153717DA325CB7269CBC1@vaebe104.NOE.Nokia.com> <20080422210355.GA12678@elstar.local> Date: Tue, 22 Apr 2008 18:54:02 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc8911791ef2377fedec8d7973d1abbb7f0e54d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.38.102 Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: "Juergen Schoenwaelder" > To: > Cc: ; > Sent: Tuesday, April 22, 2008 3:03 PM > Subject: Re: [Isms] open issues > > On Mon, Apr 21, 2008 at 07:35:32PM +0300, Pasi.Eronen@nokia.com wrote: > > Juergen Schoenwaelder wrote: > > > > > > #6 is about whether the access controls applied are for the same > > > > authenticated identity (client vs server) as in USM. I think this > > > > needs further research of who must be authenticated for each > > > > operation type, and whether the security rules about which > > > > identity must be authenticated when using an operation are > > > > consistent with SSH and USM and the architecture. > > > > > > How can we make progress on this? Would a conference call help? We > > > have gone through this before; perhaps we need to revisit the options > > > we have and come up with pro/con criterias to select one. > > > > As I'm new to this topic, could you provide e.g. some links to the > > options that have been discussed before? > > Let me try to summarize what I think is our main problem. A > traditional SNMP agent has two "modes" of operation: > > a) Management applications can query agents or modify state of an > agent. > > b) An agent can generate notifications in order to asynchronously > notify a manager that a certain event has happened. > > For the rest of the discussion, it is only important to remember that > a) implies that the manager is taking the initiative and b) implies > that the agent is taking the initiative. Once we talk about SSH as a > secure transport for SNMP, "mode" (a) implies the manager is becoming > an SSH client initiating a connection to the agent, acting as an SSH > server, while "mode" (b) implies that the agent initiates a connection > to the manager, acting as an SSH server. > > The SNMP architecture includes an access control subsystem which > resides on the agent and which is called whenever information is > communicated to the outside world. In "mode" a), all attempts to > read/write information have to pass the access control subsystem. In > "mode" b), all outgoing notifications have to pass the access control > subsystem as well. The idea is ensure that a principal can only get > access to the information he is authorized to receive, regardless > whether the information is read, written, or communicated via a > notification. > > Our problem now is that SSH authentication is asymmetric - the SSH > client authenticates the SSH server while the SSH server authenticates > an SSH user identity residing on the SSH client. As a consequence, in > "mode" a) the agent has an authenticated SSH user name to base its > access control decision on while in "mode" b), the agent has an > authenticated host identity to base its access control decision on. It > may be important to note that on a given host, there can be multiple > notification receivers with different access control requirements. > > Several options were investigated how to address this issue and so far > we have not found one that is really making people happy. Some options > considered: > > A) A notification originator may initiates the underlying TCP > connection but then the roles are swapped before the SSH exchange > beginns. This "solution" has security problems and does not work. > > B) Notifications always travel over an SSH connection that has been > initiated by a "manager" application, so we always have an > authenticated user identity for access control to work as expected. > If there is no suitable SSH connection, one can either revert to > SNMPv3/USM (means ISMS looses its value since you still need a > fully configured SNMPv3/USM infrastructure) or one can use an > unauthenticated notification to let the manager initiate a suitable > SSH connection (ugly and likely has similar security issues like > A). Furthermore, in many implementations, command generators and > notification receivers are not really tight together so using a > shared SSH connection may simply not be realistic for a large range > of existing code bases. > > C) Work around the issue by using SSH host-based authentication. This > option has issues with situations where a single host may contain > multiple notification receivers that are authorized to receive only > different subsets of notifications, see above. > > There might be more options or variations we have considered and which > I have forgotton to mention in this email. > > Was this explanation understandable? If not, keep asking questions. ... While not disagreeing with Juergen's analysis, I think it might be helpful to look at the problem in a slightly different way. Think of a notification subscription as an information retrieval request, and the notification as the (potentially much-delayed) response. How do we know the "response" (the notification) is going to the party that requested it and not someone else? After all, *anything* could have been configured as the notification destination. In the case of USM, it's the symmetric key used by the notification subscriber that implicitly makes this binding, and prevents anyone else from getting at the data first. (If the data isn't encrypted, the whole question is really moot.) With USM, there's a reasonable argument for using a separate identity for notifications for each manager/agent pair. Otherwise, the compromise of one managed element would permit the impersonation of others as notification generators. (This is discussed in RFC 3414.) Perhaps this same approach (keeping the nofitication identities distinct from those used for monitoring and configuration) might be helpful here. Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Apr 22 20:01:15 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3303A6827; Tue, 22 Apr 2008 20:01:15 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5739C3A6827 for ; Tue, 22 Apr 2008 20:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, FAKE_REPLY_C=2.012] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mf-b+iQ0HJqo for ; Tue, 22 Apr 2008 20:01:13 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 96C1D3A67EA for ; Tue, 22 Apr 2008 20:01:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=IRoI65bhIo4X4de7b6nzNWKgIaN1ng5avSqiLtdIpuhYsWcWAawAPhbVP4w6DvSA; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.38.102] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JoVEV-0006k7-1p for isms@ietf.org; Tue, 22 Apr 2008 23:01:19 -0400 Message-ID: <000801c8a4e6$126c9b40$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Tue, 22 Apr 2008 20:02:22 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117ca249f4b751342671ffaeb399cb1cefc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.38.102 Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: "Randy Presuhn" > To: > Sent: Tuesday, April 22, 2008 6:54 PM > Subject: Re: [Isms] open issues ... > Think of a notification subscription as an information retrieval request, > and the notification as the (potentially much-delayed) response. How > do we know the "response" (the notification) is going to the party that > requested it and not someone else? After all, *anything* could have > been configured as the notification destination. In the case of USM, > it's the symmetric key used by the notification subscriber that implicitly > makes this binding, and prevents anyone else from getting at the data first. > (If the data isn't encrypted, the whole question is really moot.) ... To be absolutely clear, this is *not* to say that the key used to configure the destination is remembered. The association happens through snmpTargetParamsSecurityName in the snmpTargetParamsTable. The value of snmpTargetParamsSecurityName isn't necessarily the same as the securityName in use by the entity configuring the subscription. (See section 5 of RFC 3413 for details.) Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Apr 22 23:45:50 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9249828C275; Tue, 22 Apr 2008 23:45:50 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A623A69FA for ; Tue, 22 Apr 2008 23:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SokdL5D4hE6 for ; Tue, 22 Apr 2008 23:45:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7A88B28C20C for ; Tue, 22 Apr 2008 23:45:33 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7AF3FC0022; Wed, 23 Apr 2008 08:45:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sMHiFtI8cRf7; Wed, 23 Apr 2008 08:45:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1EC1FC0026; Wed, 23 Apr 2008 08:45:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CCAE5544A6B; Wed, 23 Apr 2008 08:45:30 +0200 (CEST) Date: Wed, 23 Apr 2008 08:45:30 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20080423064530.GC13183@elstar.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <20080422210355.GA12678@elstar.local> <002401c8a4dc$869f3400$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <002401c8a4dc$869f3400$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: isms@ietf.org Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Tue, Apr 22, 2008 at 06:54:02PM -0600, Randy Presuhn wrote: > Hi - > > > From: "Juergen Schoenwaelder" > > To: > > Cc: ; > > Sent: Tuesday, April 22, 2008 3:03 PM > > Subject: Re: [Isms] open issues > > > > > On Mon, Apr 21, 2008 at 07:35:32PM +0300, Pasi.Eronen@nokia.com wrote: > > > Juergen Schoenwaelder wrote: > > > > > > > > #6 is about whether the access controls applied are for the same > > > > > authenticated identity (client vs server) as in USM. I think this > > > > > needs further research of who must be authenticated for each > > > > > operation type, and whether the security rules about which > > > > > identity must be authenticated when using an operation are > > > > > consistent with SSH and USM and the architecture. > > > > > > > > How can we make progress on this? Would a conference call help? We > > > > have gone through this before; perhaps we need to revisit the options > > > > we have and come up with pro/con criterias to select one. > > > > > > As I'm new to this topic, could you provide e.g. some links to the > > > options that have been discussed before? > > > > Let me try to summarize what I think is our main problem. A > > traditional SNMP agent has two "modes" of operation: > > > > a) Management applications can query agents or modify state of an > > agent. > > > > b) An agent can generate notifications in order to asynchronously > > notify a manager that a certain event has happened. > > > > For the rest of the discussion, it is only important to remember that > > a) implies that the manager is taking the initiative and b) implies > > that the agent is taking the initiative. Once we talk about SSH as a > > secure transport for SNMP, "mode" (a) implies the manager is becoming > > an SSH client initiating a connection to the agent, acting as an SSH > > server, while "mode" (b) implies that the agent initiates a connection > > to the manager, acting as an SSH server. > > > > The SNMP architecture includes an access control subsystem which > > resides on the agent and which is called whenever information is > > communicated to the outside world. In "mode" a), all attempts to > > read/write information have to pass the access control subsystem. In > > "mode" b), all outgoing notifications have to pass the access control > > subsystem as well. The idea is ensure that a principal can only get > > access to the information he is authorized to receive, regardless > > whether the information is read, written, or communicated via a > > notification. > > > > Our problem now is that SSH authentication is asymmetric - the SSH > > client authenticates the SSH server while the SSH server authenticates > > an SSH user identity residing on the SSH client. As a consequence, in > > "mode" a) the agent has an authenticated SSH user name to base its > > access control decision on while in "mode" b), the agent has an > > authenticated host identity to base its access control decision on. It > > may be important to note that on a given host, there can be multiple > > notification receivers with different access control requirements. > > > > Several options were investigated how to address this issue and so far > > we have not found one that is really making people happy. Some options > > considered: > > > > A) A notification originator may initiates the underlying TCP > > connection but then the roles are swapped before the SSH exchange > > beginns. This "solution" has security problems and does not work. > > > > B) Notifications always travel over an SSH connection that has been > > initiated by a "manager" application, so we always have an > > authenticated user identity for access control to work as expected. > > If there is no suitable SSH connection, one can either revert to > > SNMPv3/USM (means ISMS looses its value since you still need a > > fully configured SNMPv3/USM infrastructure) or one can use an > > unauthenticated notification to let the manager initiate a suitable > > SSH connection (ugly and likely has similar security issues like > > A). Furthermore, in many implementations, command generators and > > notification receivers are not really tight together so using a > > shared SSH connection may simply not be realistic for a large range > > of existing code bases. > > > > C) Work around the issue by using SSH host-based authentication. This > > option has issues with situations where a single host may contain > > multiple notification receivers that are authorized to receive only > > different subsets of notifications, see above. > > > > There might be more options or variations we have considered and which > > I have forgotton to mention in this email. > > > > Was this explanation understandable? If not, keep asking questions. > ... > > While not disagreeing with Juergen's analysis, I think it might be helpful to > look at the problem in a slightly different way. > > Think of a notification subscription as an information retrieval request, > and the notification as the (potentially much-delayed) response. How > do we know the "response" (the notification) is going to the party that > requested it and not someone else? After all, *anything* could have > been configured as the notification destination. In the case of USM, > it's the symmetric key used by the notification subscriber that implicitly > makes this binding, and prevents anyone else from getting at the data first. > (If the data isn't encrypted, the whole question is really moot.) I guess you talk about this option: D) The notification receiver establishes an SSH connection (acting as an SSH client) and configures the SNMP agent (acting as an SSH server) to send notifications via this SSH connection. This plays nicely with the way SNMP access control works. The drawbacks of this approach are that (i) you have to have a command responder co-located with a notification originator, (ii) it won't work with short-lived notification originators, such as snmptrap commandline utilities, (iii) you have to keep SSH connection alive to all notification receivers, and (iv) the garbage collection of notification target configurations when the SSH sessions disappear needs to be worked out (but that seems to be a minor issue). If you have something else in mind, let me know. /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 23 01:27:44 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68383A6C0B; Wed, 23 Apr 2008 01:27:44 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52C4E3A6C2D for ; Wed, 23 Apr 2008 01:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaCWG2qTjhFs for ; Wed, 23 Apr 2008 01:27:42 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 4A96D3A6B8B for ; Wed, 23 Apr 2008 01:27:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=T9pspafFT1rNDdT51Dta5z5oh5fQJXCBI2kGb9F+4oUkmOgcivR/3nW0YrFt1Qs+; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.165.5.13] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JoaKR-00029q-OV for isms@ietf.org; Wed, 23 Apr 2008 04:27:48 -0400 Message-ID: <000d01c8a513$af1af400$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080422210355.GA12678@elstar.local> <002401c8a4dc$869f3400$6801a8c0@oemcomputer> <20080423064530.GC13183@elstar.local> Date: Wed, 23 Apr 2008 01:28:53 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117a85419adc7573ff3e8f5b55d4d36372e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.165.5.13 Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, April 23, 2008 12:45 AM > Subject: Re: [Isms] open issues ... > I guess you talk about this option: > > D) The notification receiver establishes an SSH connection (acting as > an SSH client) and configures the SNMP agent (acting as an SSH > server) to send notifications via this SSH connection. This plays > nicely with the way SNMP access control works. > > The drawbacks of this approach are that (i) you have to have a > command responder co-located with a notification originator, (ii) > it won't work with short-lived notification originators, such as > snmptrap commandline utilities, (iii) you have to keep SSH > connection alive to all notification receivers, and (iv) the > garbage collection of notification target configurations when the > SSH sessions disappear needs to be worked out (but that seems to be > a minor issue). > > If you have something else in mind, let me know. ... That's not what I intended. My point was that in the USM world, the agent will have been configured with information that (1) allows an access control policy to be applied before allowing information to leave the box in a notification, and (2) prevents that information from being used by anyone else without having first passed through something that has the right key. Also of interest is (3) that the identity used for sending the notification isn't necessarily the identity used to create the subscription. (2) is *logically* authentication, but in fact in USM it's the symmetric encryption key that makes it work. I think it's pretty clear that session management for notification streams should be handled by the notification originator, short-lived or not. For the notification receiver to be responsible for creation and teardown would be much less robust and not scale as well. So if the manager is an SSH server as far as notification streams are concerned, I think things work out about as well as they do with USM (if one has configured USM to not be vulnerable to the potential compromise of an agent system.) Specifically, it means that for a notification user, a separate securityName would need to be created for each manager/agent pair. (Otherwise one agent could impersonate another.) Though the access control policy is applied on the agent, that securityName is also what would be needed to establish the SSH connection with whatever manager is to be used as the trap destination, thus giving the desired authentication, or at least as much authentication as a manger gets when it sends configuration data to an agent. Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 23 01:48:10 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AB5B3A6A39; Wed, 23 Apr 2008 01:48:10 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7E2F3A682C for ; Wed, 23 Apr 2008 01:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.424 X-Spam-Level: X-Spam-Status: No, score=-1.424 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ggbwyk6kS62T for ; Wed, 23 Apr 2008 01:47:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A451F3A6D1E for ; Wed, 23 Apr 2008 01:47:02 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7184BC0028; Wed, 23 Apr 2008 10:47:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MEv06MTbqI79; Wed, 23 Apr 2008 10:47:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23878C0004; Wed, 23 Apr 2008 10:47:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DBA0E544DC5; Wed, 23 Apr 2008 10:47:01 +0200 (CEST) Date: Wed, 23 Apr 2008 10:47:01 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20080423084701.GE13273@elstar.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <20080422210355.GA12678@elstar.local> <002401c8a4dc$869f3400$6801a8c0@oemcomputer> <20080423064530.GC13183@elstar.local> <000d01c8a513$af1af400$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <000d01c8a513$af1af400$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: isms@ietf.org Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Wed, Apr 23, 2008 at 01:28:53AM -0600, Randy Presuhn wrote: > So if the manager is an SSH server as far as notification streams > are concerned, I think things work out about as well as they do with > USM (if one has configured USM to not be vulnerable to the potential > compromise of an agent system.) Specifically, it means that for a > notification user, a separate securityName would need to be created > for each manager/agent pair. (Otherwise one agent could impersonate > another.) Though the access control policy is applied on the agent, > that securityName is also what would be needed to establish the > SSH connection with whatever manager is to be used as the trap > destination, thus giving the desired authentication, or at least as > much authentication as a manger gets when it sends configuration > data to an agent. But if the manager is the SSH server, then all you have is an authenticated host the server is running on. You made the point that there can be distinct notification receivers on the same host. So how do you solve that puzzle? /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 23 11:52:11 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF2B3A69ED; Wed, 23 Apr 2008 11:52:11 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B653A69ED for ; Wed, 23 Apr 2008 11:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGSOnf0Q+FOO for ; Wed, 23 Apr 2008 11:52:08 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id C62943A6868 for ; Wed, 23 Apr 2008 11:52:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Cue9Qxs9L8uocDQ/k7x5tIZxYvtwwz6dLynnZG5c+xaB6b5O/Dt3jwPUbr0wb1Cg; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.78.216] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Jok4h-0005v0-U3 for isms@ietf.org; Wed, 23 Apr 2008 14:52:12 -0400 Message-ID: <000601c8a56a$e95f1c20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080422210355.GA12678@elstar.local> <002401c8a4dc$869f3400$6801a8c0@oemcomputer> <20080423064530.GC13183@elstar.local> <000d01c8a513$af1af400$6801a8c0@oemcomputer> <20080423084701.GE13273@elstar.local> Date: Wed, 23 Apr 2008 11:53:16 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc8911757b9456b48dcbb0d7524779ae2127488350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.78.216 Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, April 23, 2008 2:47 AM > Subject: Re: [Isms] open issues ... > But if the manager is the SSH server, then all you have is an > authenticated host the server is running on. You made the point that > there can be distinct notification receivers on the same host. So how > do you solve that puzzle? ... I don't. Our architecture, both on the manager and on the agent ends, strongly assumes that security mechanisms are able to authenticate to the granularity of a principal. RFC 3411 sections 3.2.1 and 3.2.2 should make that clear. If SSH doesn't provide (or can't be made to provide) that service, then it's not suitable. It's as simple as that. Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 23 14:33:48 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918563A69BE; Wed, 23 Apr 2008 14:33:48 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A983A6818 for ; Wed, 23 Apr 2008 14:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.542 X-Spam-Level: X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pFVAc1edw0x for ; Wed, 23 Apr 2008 14:33:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 74D7A3A6960 for ; Wed, 23 Apr 2008 14:33:45 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 859CDC000A; Wed, 23 Apr 2008 23:33:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4lPH6OZ699lB; Wed, 23 Apr 2008 23:33:45 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE708C0006; Wed, 23 Apr 2008 23:33:43 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B5094545904; Wed, 23 Apr 2008 23:33:43 +0200 (CEST) Date: Wed, 23 Apr 2008 23:33:43 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20080423213343.GA14614@elstar.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <20080422210355.GA12678@elstar.local> <002401c8a4dc$869f3400$6801a8c0@oemcomputer> <20080423064530.GC13183@elstar.local> <000d01c8a513$af1af400$6801a8c0@oemcomputer> <20080423084701.GE13273@elstar.local> <000601c8a56a$e95f1c20$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <000601c8a56a$e95f1c20$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: isms@ietf.org Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Wed, Apr 23, 2008 at 11:53:16AM -0600, Randy Presuhn wrote: > I don't. Our architecture, both on the manager and on the agent ends, > strongly assumes that security mechanisms are able to authenticate > to the granularity of a principal. RFC 3411 sections 3.2.1 and 3.2.2 > should make that clear. If SSH doesn't provide (or can't be made to > provide) that service, then it's not suitable. It's as simple as that. Here is the relevant text (for those who are too lazy to look it up): 3.2.1. Principal A principal is the "who" on whose behalf services are provided or processing takes place. A principal can be, among other things, an individual acting in a particular role; a set of individuals, with each acting in a particular role; an application or a set of applications; and combinations thereof. 3.2.2. securityName A securityName is a human readable string representing a principal. It has a model-independent format, and can be used outside a particular Security Model. So is the conclusion here that SSH is a dead end? Do we have to revisit the discussion of SSH vs. TLS? /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 23 16:02:34 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B90C73A693E; Wed, 23 Apr 2008 16:02:34 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9667A3A693E for ; Wed, 23 Apr 2008 16:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHA8+XJKsxnE for ; Wed, 23 Apr 2008 16:02:32 -0700 (PDT) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 58A403A68B5 for ; Wed, 23 Apr 2008 16:02:32 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id H5i71Z00317UAYkA40UL00; Wed, 23 Apr 2008 23:00:55 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id HB2W1Z0064HwxpC8Z00000; Wed, 23 Apr 2008 23:02:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=14hpN8IPmG0FgnqXBe0A:9 a=hU3U4pFTHUWH8KD_qjEA:7 a=58uok_S-f2uwd8hI84NX2Fz1r1oA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , "'Randy Presuhn'" References: <20080422210355.GA12678@elstar.local><002401c8a4dc$869f3400$6801a8c0@oemcomputer><20080423064530.GC13183@elstar.local><000d01c8a513$af1af400$6801a8c0@oemcomputer><20080423084701.GE13273@elstar.local><000601c8a56a$e95f1c20$6801a8c0@oemcomputer> <20080423213343.GA14614@elstar.local> Date: Wed, 23 Apr 2008 19:02:30 -0400 Message-ID: <019101c8a596$1c8a1cf0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080423213343.GA14614@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcilibxmuYQLKRZaTxOqsZdCqzaA6wACv9BQ Cc: isms@ietf.org Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi, I think we need to make it clear (assuming we don't find a way to solve this problem) that operators need to understand that notifications over SSH can only be delivered to host granularity, not to user-level granularity. Since ACM uses securityName/securityModel, this would actually apply to any transport model that uses TSM. I am not convinced that host-level granularity satisfies the operators' requests for database access controls. If host-level is enough for operators, including for GET/SET requests, then we can control access based on (authenticated host) transport address rather than authenticated user, and greatly simplify SNMPv3. This is not what Enterasys customers asked for; they wanted user-granularity authentication and access controls. If the granularity of access control for notifications is different than the granularity for GET/SET requests, we need to consider security implications of reporting something to a user in a trap that he is not authorized to see using a GET request. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Wednesday, April 23, 2008 5:34 PM > To: Randy Presuhn > Cc: isms@ietf.org > Subject: Re: [Isms] open issues > > On Wed, Apr 23, 2008 at 11:53:16AM -0600, Randy Presuhn wrote: > > > I don't. Our architecture, both on the manager and on the > agent ends, > > strongly assumes that security mechanisms are able to authenticate > > to the granularity of a principal. RFC 3411 sections 3.2.1 > and 3.2.2 > > should make that clear. If SSH doesn't provide (or can't be made to > > provide) that service, then it's not suitable. It's as > simple as that. > > Here is the relevant text (for those who are too lazy to look it up): > > 3.2.1. Principal > > A principal is the "who" on whose behalf services are provided or > processing takes place. > > A principal can be, among other things, an individual acting in a > particular role; a set of individuals, with each acting in a > particular role; an application or a set of applications; and > combinations thereof. > > 3.2.2. securityName > > A securityName is a human readable string representing a > principal. > It has a model-independent format, and can be used outside a > particular Security Model. > > So is the conclusion here that SSH is a dead end? Do we have > to revisit > the discussion of SSH vs. TLS? > > /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@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 23 16:46:49 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6EA23A6D20; Wed, 23 Apr 2008 16:46:49 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6178A3A6C2D for ; Wed, 23 Apr 2008 16:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gD7CzBHHu5o for ; Wed, 23 Apr 2008 16:46:47 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 3C77B3A6AEE for ; Wed, 23 Apr 2008 16:46:46 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA07.westchester.pa.mail.comcast.net with comcast id YKDf1Z0030Fqzac5707m00; Wed, 23 Apr 2008 23:13:49 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA08.westchester.pa.mail.comcast.net with comcast id HBDj1Z00524Kx1C3U00000; Wed, 23 Apr 2008 23:13:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=QGc0G1UW6JwLC9DmFoUA:9 a=eYXRKbFkp-qjEuvY9xQKOehLNo0A:4 a=QJAqVYndk0IA:10 From: "David B. Nelson" To: References: <20080422210355.GA12678@elstar.local><002401c8a4dc$869f3400$6801a8c0@oemcomputer><20080423064530.GC13183@elstar.local><000d01c8a513$af1af400$6801a8c0@oemcomputer><20080423084701.GE13273@elstar.local> <000601c8a56a$e95f1c20$6801a8c0@oemcomputer> Date: Wed, 23 Apr 2008 19:13:48 -0400 Message-ID: <000001c8a597$b0349560$011716ac@NEWTON603> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcilcyiJyFbInvdBQLOkKJ0u1qVGAgAIePMA In-Reply-To: <000601c8a56a$e95f1c20$6801a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Randy Presuhn writes... > Our architecture, both on the manager and on the agent ends, > strongly assumes that security mechanisms are able to authenticate > to the granularity of a principal. RFC 3411 sections 3.2.1 and 3.2.2 > should make that clear. If SSH doesn't provide (or can't be made to > provide) that service, then it's not suitable. The authentication inherent to SSH is asymmetric. It was originally designed to facilitate users logging into remote hosts. An SSH client is able (by various SSH Authentication Methods) to authenticate to an SSH server at the granularity of a principal. An SSH server authenticates to the SSH client at the granularity of a host (i.e. the host identity of the SSH server). If you assume that the shared keys of USM are shared at the granularity of a principal at both the agent and management station ends on an SNMP connection, then USM provides symmetric authentication at the granularly of a principal. In order to provide authentication at the granularity of a principal in the notification case for SSHTM, one would presumably require that the agent act as an SSH client and present principal granularity credentials for authentication by the SSH server, i.e. the management station. The fly in the ointment here is that one of the primary reasons for having SSHTM is to avoid the need to provision credentials (at principal granularity) on all the managed entities in an organization. In the case of a management station sending SNMP commands to an agent, we assume that the management station application, or the user invoking that application, has an identity that can be validated via some method such as AAA, at the agent. That identity may become from some non-volatile configuration store, or it may come from the user's login credentials. I think that the latter case is more common. It is perfectly possible to provision device credentials in the non-volatile configuration store of the managed entities (notification generators) if you are willing to experience USM-like scaling properties. _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 23 17:34:33 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3963A6BAF; Wed, 23 Apr 2008 17:34:33 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D51F3A6BAF for ; Wed, 23 Apr 2008 17:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDVCLDe5UYze for ; Wed, 23 Apr 2008 17:34:31 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 3229D3A6A5F for ; Wed, 23 Apr 2008 17:34:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=P66OaUAidh+kcNVCGUjxlm3x79LbIS6BFu/SZs6gNR6SOE9UIHoQNV8KWbsuFM0d; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.90.229] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JopQ4-0003zl-61 for isms@ietf.org; Wed, 23 Apr 2008 20:34:36 -0400 Message-ID: <000c01c8a59a$c04122e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080422210355.GA12678@elstar.local><002401c8a4dc$869f3400$6801a8c0@oemcomputer><20080423064530.GC13183@elstar.local><000d01c8a513$af1af400$6801a8c0@oemcomputer><20080423084701.GE13273@elstar.local><000601c8a56a$e95f1c20$6801a8c0@oemcomputer> <000001c8a597$b0349560$011716ac@NEWTON603> Date: Wed, 23 Apr 2008 17:35:43 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117cb9ecdbf929b47eb461c9c7033797416350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.90.229 Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: "David B. Nelson" > To: > Sent: Wednesday, April 23, 2008 5:13 PM > Subject: Re: [Isms] open issues > > Randy Presuhn writes... > > > Our architecture, both on the manager and on the agent ends, > > strongly assumes that security mechanisms are able to authenticate > > to the granularity of a principal. RFC 3411 sections 3.2.1 and 3.2.2 > > should make that clear. If SSH doesn't provide (or can't be made to > > provide) that service, then it's not suitable. > > The authentication inherent to SSH is asymmetric. It was originally > designed to facilitate users logging into remote hosts. An SSH client is > able (by various SSH Authentication Methods) to authenticate to an SSH > server at the granularity of a principal. An SSH server authenticates to > the SSH client at the granularity of a host (i.e. the host identity of the > SSH server). > > If you assume that the shared keys of USM are shared at the granularity of a > principal at both the agent and management station ends on an SNMP > connection, then USM provides symmetric authentication at the granularly of > a principal. With key localization, this is indeed how it works for command generators and responders. For the notification case it *can* work the same way, though with an unfortunate proliferation of securityNames and associated keys. (Keeping it simple opens the possibility that a compromised notification generator could impersonate another.) > In order to provide authentication at the granularity of a principal in the > notification case for SSHTM, one would presumably require that the agent act > as an SSH client and present principal granularity credentials for > authentication by the SSH server, i.e. the management station. This sounds fine. > The fly in the ointment here is that one of the primary reasons for having > SSHTM is to avoid the need to provision credentials (at principal > granularity) on all the managed entities in an organization. In the case of > a management station sending SNMP commands to an agent, we assume that the > management station application, or the user invoking that application, has > an identity that can be validated via some method such as AAA, at the agent. > That identity may become from some non-volatile configuration store, or it > may come from the user's login credentials. I think that the latter case is > more common. > > It is perfectly possible to provision device credentials in the non-volatile > configuration store of the managed entities (notification generators) if you > are willing to experience USM-like scaling properties. It'd be no worse than USM. That sounds like a victory. :-) Before descending into gloom it might be helpful to carefully think through the trust model for notification receivers in USM, to understand whether it is really necessary to go that far. In the USM world, the transmitting SNMP engine uses the securityName to determine whether the information in the notification should be allowed to leave the box. The SNMP engine receiving that notification uses the authentication information to make sure the information is genuine. How does the sender know the notification has gone to the "right" user? All it *really* knows is that the SNMP engine for the notification receiver has to have that shared key in order to decrypt the payload, and that the notification's ultimate consumer must have entrusted that engine with the key. This gives us an implicit two-way authentication, at least as far as the protocol engines. In terms of demultiplexing incoming notification streams to the correct user of the management system, whether based on securityName or something else, all RFC 3413 has to say in section 3.4 (3) is "After this, processing depends on the particular implementation." Consequently, I think whether collapsing things down to a single securityName per agent for incoming notifications would be adequate depends on the extent to which implementations of notification receiver applications rely on securityName to demultiplex notifications corresponding to different "subscriptions." Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 23 23:33:06 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07B13A6AAC; Wed, 23 Apr 2008 23:33:06 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A31F3A6A7E for ; Wed, 23 Apr 2008 23:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1JhaDSumlfH for ; Wed, 23 Apr 2008 23:32:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 01EC03A6AAC for ; Wed, 23 Apr 2008 23:32:57 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 90BA5C0011; Thu, 24 Apr 2008 08:33:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mih7wVfjBOVX; Thu, 24 Apr 2008 08:32:57 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64156C000A; Thu, 24 Apr 2008 08:32:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 01EAF545EA4; Thu, 24 Apr 2008 08:32:55 +0200 (CEST) Date: Thu, 24 Apr 2008 08:32:55 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20080424063255.GA15020@elstar.local> Mail-Followup-To: David Harrington , 'Randy Presuhn' , isms@ietf.org References: <20080423213343.GA14614@elstar.local> <019101c8a596$1c8a1cf0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <019101c8a596$1c8a1cf0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: isms@ietf.org Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Wed, Apr 23, 2008 at 07:02:30PM -0400, David Harrington wrote: > Since ACM uses securityName/securityModel, this would actually apply > to any transport model that uses TSM. I fail to see why. Suppose I have a secure transport where the principals at both endpoints are authenticated using say PGP keys. Why should TSM then not be able to do the right thing? /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Apr 24 01:08:37 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401EE3A6907; Thu, 24 Apr 2008 01:08:37 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32EFF3A68B9 for ; Thu, 24 Apr 2008 01:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbsaXZwlbMfC for ; Thu, 24 Apr 2008 01:08:34 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id 3D6A33A6A0C for ; Thu, 24 Apr 2008 01:08:34 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id HL6r1Z0020b6N64A700F00; Thu, 24 Apr 2008 08:08:38 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id HL8a1Z0014HwxpC8P00000; Thu, 24 Apr 2008 08:08:39 +0000 X-Authority-Analysis: v=1.0 c=1 a=j3Z76cjpAAAA:8 a=pqXqhgGz48SwBJlvTgQA:9 a=5I50N03dZrDh3t3_5BwqEfukm34A:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=7OmpBygbiDMA:10 From: "David Harrington" To: References: <20080423213343.GA14614@elstar.local> <019101c8a596$1c8a1cf0$0600a8c0@china.huawei.com> <20080424063255.GA15020@elstar.local> Date: Thu, 24 Apr 2008 04:08:34 -0400 Message-ID: <01a601c8a5e2$651d7380$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20080424063255.GA15020@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: Acil1Q3omC89rJQaT26TyEzQ0KpZGQACropQ Cc: isms@ietf.org Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org OK. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, April 24, 2008 2:33 AM > To: David Harrington > Cc: 'Randy Presuhn'; isms@ietf.org > Subject: Re: [Isms] open issues > > On Wed, Apr 23, 2008 at 07:02:30PM -0400, David Harrington wrote: > > > Since ACM uses securityName/securityModel, this would actually apply > > to any transport model that uses TSM. > > I fail to see why. Suppose I have a secure transport where the > principals at both endpoints are authenticated using say PGP keys. > Why should TSM then not be able to do the right thing? > > /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Apr 24 10:44:57 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789C23A694B; Thu, 24 Apr 2008 10:44:57 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29083A692E for ; Thu, 24 Apr 2008 10:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.213 X-Spam-Level: X-Spam-Status: No, score=-4.213 tagged_above=-999 required=5 tests=[AWL=-1.614, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh7zaxrLGpfd for ; Thu, 24 Apr 2008 10:44:56 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id 686F43A694B for ; Thu, 24 Apr 2008 10:44:55 -0700 (PDT) Received: from mgw-mx06.nokia.com (mgw-mx06.nokia.com [192.100.122.233]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3OHiunh004642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Apr 2008 20:44:57 +0300 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3OHiTJ2017670; Thu, 24 Apr 2008 20:44:35 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Apr 2008 20:44:34 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Apr 2008 20:44:34 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 20:44:33 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7271D491@vaebe104.NOE.Nokia.com> In-Reply-To: <000c01c8a59a$c04122e0$6801a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] open issues Thread-index: AcilowCfSKS5R8trTGCh9DKYjPbg5wAjPmUA References: <20080422210355.GA12678@elstar.local><002401c8a4dc$869f3400$6801a8c0@oemcomputer><20080423064530.GC13183@elstar.local><000d01c8a513$af1af400$6801a8c0@oemcomputer><20080423084701.GE13273@elstar.local><000601c8a56a$e95f1c20$6801a8c0@oemcomputer><000001c8a597$b0349560$011716ac@NEWTON603> <000c01c8a59a$c04122e0$6801a8c0@oemcomputer> From: "Pasi.Eronen@nokia.com" To: , X-OriginalArrivalTime: 24 Apr 2008 17:44:34.0247 (UTC) FILETIME=[DB92DD70:01C8A632] X-Nokia-AV: Clean Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Randy Presuhn wrote: > In the USM world, the transmitting SNMP engine uses the securityName > to determine whether the information in the notification should be > allowed to leave the box. The SNMP engine receiving that > notification uses the authentication information to make sure the > information is genuine. How does the sender know the notification > has gone to the "right" user? All it *really* knows is that the > SNMP engine for the notification receiver has to have that shared > key in order to decrypt the payload, and that the notification's > ultimate consumer must have entrusted that engine with the key. > This gives us an implicit two-way authentication, at least as far as > the protocol engines. In terms of demultiplexing incoming > notification streams to the correct user of the management system, > whether based on securityName or something else, all RFC 3413 has to > say in section 3.4 (3) is "After this, processing depends on the > particular implementation." I guess in case of SSH, this would mean that the notification originator (acting as SSH client) needs to know: in the application: - transportAddress (of the destination) - securityName (used primarily to determine whether this information should be allowed to leave the box) in SSHTM (or somewhere): for each (transportAddress, securityName) pair, how to do authentication in ssh client role: - user name to send in SSH - authentication method (e.g., password or publickey) - the secret to use (e.g., password, private key) in SSH: - for each transportAddress, the host public key It seems that in this direction, the securityName and SSH user name won't be the same: securityName would identify someone who's allowed to see the information ("researchDeptAdmins" or "John"), but SSH user name would identify the notification originator ("router37" or "switch12.44.subunit7.example.com"), right? (In the command generator case, the securityName and SSH user name identify the same principal, so they could be the same.) > Consequently, I think whether collapsing things down to a single > securityName per agent for incoming notifications would be adequate > depends on the extent to which implementations of notification > receiver applications rely on securityName to demultiplex > notifications corresponding to different "subscriptions." BTW, is the securityName only handled solely by the security model, or is it included somewhere inside the PDU even when you're using SSHTM? If it's not, could we somehow include it just for this purpose (allowing notification receiver to do internal processing)? Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Apr 24 11:07:28 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C5A3A680A; Thu, 24 Apr 2008 11:07:28 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8707C3A67A7 for ; Thu, 24 Apr 2008 11:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.011 X-Spam-Level: X-Spam-Status: No, score=-6.011 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9gkQaC9JRgv for ; Thu, 24 Apr 2008 11:07:26 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id EC7C83A6AE4 for ; Thu, 24 Apr 2008 11:07:25 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3OI7IJJ005732; Thu, 24 Apr 2008 21:07:28 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Apr 2008 21:07:15 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 24 Apr 2008 21:07:15 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 21:07:14 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7271D4AF@vaebe104.NOE.Nokia.com> In-Reply-To: <20080423213343.GA14614@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] open issues Thread-index: AcilicBpNXZ99bEqRdWsf3W4ZuQVSwAqjKpw References: <20080422210355.GA12678@elstar.local><002401c8a4dc$869f3400$6801a8c0@oemcomputer><20080423064530.GC13183@elstar.local><000d01c8a513$af1af400$6801a8c0@oemcomputer><20080423084701.GE13273@elstar.local><000601c8a56a$e95f1c20$6801a8c0@oemcomputer> <20080423213343.GA14614@elstar.local> From: To: X-OriginalArrivalTime: 24 Apr 2008 18:07:15.0698 (UTC) FILETIME=[070FCD20:01C8A636] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Juergen Schoenwaelder wrote: > So is the conclusion here that SSH is a dead end? Do we have to > revisit the discussion of SSH vs. TLS? I'm not sure if the situation would be considerably simpler even with TLS... or it would require small extensions to TLS. Suppose a command responder authenticates connections with TLS and client certificates. A certificate from trusted CA, containing name "john.admin@example.com", would give access with that securityName, and things would probably largely as you'd expect. However, for the notification originator part, if the same transportAddress has multiple different notification receivers, the notification originator, when starting TLS handshake, would need to tell the receiver "I have stuff to send to john.admin@example.com", so that the receiver would know to authenticate with that certificate (instead of, say, "mgmtpc4.example.com" or "alice.admin@example.com"). Current TLS doesn't support that; you'd need to extend the the server_name TLS extension to support other types of identities than host names. And if a given transportAddress has just one principal behind it, we don't really have problems with SSH either, right? On the other hand, even if you do have multiple principals, the software receiving the connection would still have access to both John's and Alice's private keys. So we're trusting it anyway... What if the SSHTM also included a security model that didn't actually do any crypto or anything, but just included the securityName in the PDU so that the notification recipient could do internal processing (knowing that this notification should be seen only by John)? Or perhaps there are some easier ways to achieve this? Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Apr 24 11:31:28 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653B73A6B08; Thu, 24 Apr 2008 11:31:28 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ADBE3A6875 for ; Thu, 24 Apr 2008 11:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6cbZGgX0c51 for ; Thu, 24 Apr 2008 11:31:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 162293A6C4E for ; Thu, 24 Apr 2008 11:31:25 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 19EC8C000F; Thu, 24 Apr 2008 20:31:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id itOAICZHXlVK; Thu, 24 Apr 2008 20:31:24 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E7CAC0002; Thu, 24 Apr 2008 20:31:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3A7AD5476BA; Thu, 24 Apr 2008 20:31:23 +0200 (CEST) Date: Thu, 24 Apr 2008 20:31:23 +0200 From: Juergen Schoenwaelder To: Pasi.Eronen@nokia.com Message-ID: <20080424183123.GF17532@elstar.local> Mail-Followup-To: Pasi.Eronen@nokia.com, isms@ietf.org References: <20080423213343.GA14614@elstar.local> <1696498986EFEC4D9153717DA325CB7271D4AF@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1696498986EFEC4D9153717DA325CB7271D4AF@vaebe104.NOE.Nokia.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: isms@ietf.org Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org On Thu, Apr 24, 2008 at 09:07:14PM +0300, Pasi.Eronen@nokia.com wrote: > I'm not sure if the situation would be considerably simpler even with > TLS... or it would require small extensions to TLS. > > Suppose a command responder authenticates connections with TLS and > client certificates. A certificate from trusted CA, containing name > "john.admin@example.com", would give access with that securityName, > and things would probably largely as you'd expect. > > However, for the notification originator part, if the same > transportAddress has multiple different notification receivers, the > notification originator, when starting TLS handshake, would need to > tell the receiver "I have stuff to send to john.admin@example.com", > so that the receiver would know to authenticate with that certificate > (instead of, say, "mgmtpc4.example.com" or "alice.admin@example.com"). > > Current TLS doesn't support that; you'd need to extend the > the server_name TLS extension to support other types of identities > than host names. Thanks, this is valuable to know. > And if a given transportAddress has just one principal behind it, > we don't really have problems with SSH either, right? Almost. And SSH hostkey, as I understand it, identifies a host, not just a transport endpoint. But there might be ways to weak SSH to use different hostkeys for different transport endpoints on the same host. > On the other hand, even if you do have multiple principals, the > software receiving the connection would still have access to both > John's and Alice's private keys. So we're trusting it anyway... > > What if the SSHTM also included a security model that didn't > actually do any crypto or anything, but just included the > securityName in the PDU so that the notification recipient could > do internal processing (knowing that this notification should > be seen only by John)? Or perhaps there are some easier ways > to achieve this? I am not so much concerned about the multiplexing on the notification receiver side. The real issue is that we need an authenticated principal for the access control to work correctly and there might be several different principals behind the same notification receiver endpoint. /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@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Apr 24 11:54:36 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC033A6AC0; Thu, 24 Apr 2008 11:54:36 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14CD3A6AA3 for ; Thu, 24 Apr 2008 11:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHMlFEUC9mhR for ; Thu, 24 Apr 2008 11:54:34 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 190303A6873 for ; Thu, 24 Apr 2008 11:54:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=PNkebgNjjEj43rCQIpMTXMmclIBQA2f0PTv44RHUODE1Z30ABhGcbFjeU+C5qwjL; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.136.97] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Jp6ac-0005Zz-7A for isms@ietf.org; Thu, 24 Apr 2008 14:54:38 -0400 Message-ID: <010301c8a634$464caf00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080422210355.GA12678@elstar.local><002401c8a4dc$869f3400$6801a8c0@oemcomputer><20080423064530.GC13183@elstar.local><000d01c8a513$af1af400$6801a8c0@oemcomputer><20080423084701.GE13273@elstar.local><000601c8a56a$e95f1c20$6801a8c0@oemcomputer><000001c8a597$b0349560$011716ac@NEWTON603> <000c01c8a59a$c04122e0$6801a8c0@oemcomputer> <1696498986EFEC4D9153717DA325CB7271D491@vaebe104.NOE.Nokia.com> Date: Thu, 24 Apr 2008 11:54:41 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117f2a9527eae0b31cee6a0a870b16f3264350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.97 Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: > To: ; > Sent: Thursday, April 24, 2008 11:44 AM > Subject: RE: [Isms] open issues ... > It seems that in this direction, the securityName and SSH user name > won't be the same: securityName would identify someone who's allowed > to see the information ("researchDeptAdmins" or "John"), but SSH user > name would identify the notification originator ("router37" or > "switch12.44.subunit7.example.com"), right? Perhaps there's an implementation / deployment choice here, driven by the trust model. When a notification stream is presented to a management application, whose credentials would one want to use to decide whether to accept that stream? Ones associated with the subscriber, ones associated with the agent, or ones associated with both (i.e. that subscriber at that agent, as in a paranoid USM deployment)? The second consideration is whether existing notification receiver applications are using securityName to figure out where to internally (within the management system) route notifications. This is outside the scope of what we nail down in the SNMP specifications, but would be a practical consideration. We need to hear from the management application people. ... > BTW, is the securityName only handled solely by the security model, > or is it included somewhere inside the PDU even when you're using > SSHTM? ... RFC 3413 section 3.4 specifies that securityName is provided to the notification receiver application. Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Apr 24 12:06:10 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 306E83A6D18; Thu, 24 Apr 2008 12:06:10 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C1D28C490 for ; Thu, 24 Apr 2008 12:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vew4wCinoVl2 for ; Thu, 24 Apr 2008 12:05:46 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 8521E28C311 for ; Thu, 24 Apr 2008 12:03:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=W8WqMk47B9mvKS1PB1kz8tQrAsQi5gZFLeDtPYVtMeUJlPNg5MSUIAbLe3QrXcUl; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [64.105.136.97] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Jp6jG-0007x5-DE for isms@ietf.org; Thu, 24 Apr 2008 15:03:34 -0400 Message-ID: <010801c8a635$8604d400$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080423213343.GA14614@elstar.local><1696498986EFEC4D9153717DA325CB7271D4AF@vaebe104.NOE.Nokia.com> <20080424183123.GF17532@elstar.local> Date: Thu, 24 Apr 2008 12:03:37 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117ce257d172989aa20fd50e5ff38254068350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.105.136.97 Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: "Juergen Schoenwaelder" > To: > Cc: > Sent: Thursday, April 24, 2008 12:31 PM > Subject: Re: [Isms] open issues ... > I am not so much concerned about the multiplexing on the notification > receiver side. The real issue is that we need an authenticated > principal for the access control to work correctly and there might be > several different principals behind the same notification receiver > endpoint. ... With USM, even though the privacy key gives us the other half of the authentication, we *still* have to trust the notification receiver to demultiplex things correctly, and that's beyond the scope of the SNMP RFCs. So I think the real concern has be making sure that the SNMP engine in front of the notification receiver application is indeed the one requested by the subscriber, while still maintaining sufficient information in the PDU to permit demultiplexing. The question would still arise about the possibility of a forged subscription, but that is handled through the design of the target and notification MIBS in conjunction with VACM, as long as we don't start coalescing securityNames. Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Apr 25 11:27:17 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 895EA3A6CB8; Fri, 25 Apr 2008 11:27:17 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE153A6CFC for ; Fri, 25 Apr 2008 11:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.796 X-Spam-Level: X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HY0o7Wx8QFL for ; Fri, 25 Apr 2008 11:27:15 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 416363A69F3 for ; Fri, 25 Apr 2008 11:27:15 -0700 (PDT) Received: from leeuwarden.cs.utwente.nl (leeuwarden.ewi.utwente.nl [130.89.10.54]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m3PIRJTC016684 for ; Fri, 25 Apr 2008 20:27:19 +0200 (MEST) Received: from [192.168.1.100] (warnsinklanden.adsl.utwente.nl [130.89.229.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by leeuwarden.cs.utwente.nl (Postfix) with ESMTP id CEC2C37C802 for ; Fri, 25 Apr 2008 20:27:22 +0200 (CEST) Message-Id: <8188A584-C5D6-435B-819C-BA9F1A9EFC99@utwente.nl> From: Aiko Pras To: isms@ietf.org Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 25 Apr 2008 20:27:18 +0200 X-Mailer: Apple Mail (2.919.2) X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 25 Apr 2008 20:27:19 +0200 (MEST) Subject: [Isms] Review of draft-ietf-isms-radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi I've reviewed the internet-draft and have only a couple of editorial comments. I've scanned these comments, and made them available to the authors. Regards Aiko Pras _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 30 00:02:01 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CDEE3A6811; Wed, 30 Apr 2008 00:02:01 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009BE3A67FF for ; Wed, 30 Apr 2008 00:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyw9N8F36I1n for ; Wed, 30 Apr 2008 00:01:59 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id C24DF3A6811 for ; Wed, 30 Apr 2008 00:01:58 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3U71tnR029593; Wed, 30 Apr 2008 10:01:58 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Apr 2008 10:01:40 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Apr 2008 10:01:39 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 10:01:37 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB727BC9D2@vaebe104.NOE.Nokia.com> In-Reply-To: <20080424183123.GF17532@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] open issues Thread-index: AcimOWwYB/qWbrmZRHiHq14Yf7pYRAEVmPFg References: <20080423213343.GA14614@elstar.local> <1696498986EFEC4D9153717DA325CB7271D4AF@vaebe104.NOE.Nokia.com> <20080424183123.GF17532@elstar.local> From: To: X-OriginalArrivalTime: 30 Apr 2008 07:01:39.0863 (UTC) FILETIME=[09ED7A70:01C8AA90] X-Nokia-AV: Clean Cc: isms@ietf.org Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Juergen Schoenwaelder wrote: > > And if a given transportAddress has just one principal behind it, > > we don't really have problems with SSH either, right? > > Almost. And SSH hostkey, as I understand it, identifies a host, not > just a transport endpoint. But there might be ways to weak SSH to use > different hostkeys for different transport endpoints on the same host. Although the SSH RFCs talks about "hosts", if a host would have more than one SSH server running, they could have different "host" keys (just like if you have multiple applications using TLS on the same host, they might need different certificates). > > On the other hand, even if you do have multiple principals, the > > software receiving the connection would still have access to both > > John's and Alice's private keys. So we're trusting it anyway... > > > > What if the SSHTM also included a security model that didn't > > actually do any crypto or anything, but just included the > > securityName in the PDU so that the notification recipient could > > do internal processing (knowing that this notification should > > be seen only by John)? Or perhaps there are some easier ways > > to achieve this? > > I am not so much concerned about the multiplexing on the notification > receiver side. The real issue is that we need an authenticated > principal for the access control to work correctly and there might be > several different principals behind the same notification receiver > endpoint. Do you mean access control on the notification receiver side, or on the notification originator side? (I think we can handle the latter: the securityName given by the notification originator application would identify the intended recipient, and would be used for access control on the notification originator side -- but the SSH user name sent when connecting to the notification receiver would identify the originator.) Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 30 00:02:47 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7023A699D; Wed, 30 Apr 2008 00:02:47 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54D843A6B4C for ; Wed, 30 Apr 2008 00:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0xDdeZ6tJsv for ; Wed, 30 Apr 2008 00:02:44 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 2CAFF3A6B3A for ; Wed, 30 Apr 2008 00:02:43 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3U72aNd030292; Wed, 30 Apr 2008 10:02:44 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Apr 2008 10:02:43 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Apr 2008 10:02:43 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 10:02:41 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB727BC9D4@vaebe104.NOE.Nokia.com> In-Reply-To: <010301c8a634$464caf00$6801a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] open issues Thread-index: AcimPK0izdKZztpKT4iL4gqiMd1R6wEU11hg References: <20080422210355.GA12678@elstar.local><002401c8a4dc$869f3400$6801a8c0@oemcomputer><20080423064530.GC13183@elstar.local><000d01c8a513$af1af400$6801a8c0@oemcomputer><20080423084701.GE13273@elstar.local><000601c8a56a$e95f1c20$6801a8c0@oemcomputer><000001c8a597$b0349560$011716ac@NEWTON603><000c01c8a59a$c04122e0$6801a8c0@oemcomputer><1696498986EFEC4D9153717DA325CB7271D491@vaebe104.NOE.Nokia.com> <010301c8a634$464caf00$6801a8c0@oemcomputer> From: To: , X-OriginalArrivalTime: 30 Apr 2008 07:02:43.0287 (UTC) FILETIME=[2FBB3670:01C8AA90] X-Nokia-AV: Clean Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Randy Presuhn wrote: > > It seems that in this direction, the securityName and SSH user > > name won't be the same: securityName would identify someone > > who's allowed to see the information ("researchDeptAdmins" or > > "John"), but SSH user name would identify the notification > > originator ("router37" or "switch12.44.subunit7.example.com"), > > right? > > Perhaps there's an implementation / deployment choice here, > driven by the trust model. When a notification stream is > presented to a management application, whose credentials > would one want to use to decide whether to accept that stream? > Ones associated with the subscriber, ones associated with the > agent, or ones associated with both (i.e. that subscriber at that > agent, as in a paranoid USM deployment)? Perhaps we're discovering a limitation that RFC 341x didn't really consider: when you use pairwise secret keys, the key (and its securityName) always identifies (at least implicitly) both ends of the relationship. In case of public key crypto, that's not the case. > The second consideration is whether existing notification receiver > applications are using securityName to figure out where to internally > (within the management system) route notifications. This is outside > the scope of what we nail down in the SNMP specifications, but would > be a practical consideration. We need to hear from the management > application people. > > ... > > BTW, is the securityName only handled solely by the security model, > > or is it included somewhere inside the PDU even when you're using > > SSHTM? > ... > > RFC 3413 section 3.4 specifies that securityName is provided > to the notification receiver application. Yes.. but it's not clear whether this is always the same securityName that was provided by the notification originator application (identifying the receiver, used for access control on the originator side), or a securityName identifying the originator. For pairwise secret keys, it doesn't matter. For public keys, if it's important to know the former on the notification receiver side, we might need to pass it separately from the SSH user name. Best regards, Pasi _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 30 09:19:44 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5897128C3EE; Wed, 30 Apr 2008 09:19:44 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1C228C3EE for ; Wed, 30 Apr 2008 09:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVLc529ge7ir for ; Wed, 30 Apr 2008 09:19:42 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 62BC228C3F9 for ; Wed, 30 Apr 2008 09:19:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=EqVBjphFgqPVPempmbn9UTObKHbjjfyX58pvWF2Qh6+7BacQSpnGWbUYqBOWl4cn; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.90.53] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JrF1z-0008Vh-W6 for isms@ietf.org; Wed, 30 Apr 2008 12:19:44 -0400 Message-ID: <002d01c8aad5$a91c0180$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080422210355.GA12678@elstar.local><002401c8a4dc$869f3400$6801a8c0@oemcomputer><20080423064530.GC13183@elstar.local><000d01c8a513$af1af400$6801a8c0@oemcomputer><20080423084701.GE13273@elstar.local><000601c8a56a$e95f1c20$6801a8c0@oemcomputer><000001c8a597$b0349560$011716ac@NEWTON603><000c01c8a59a$c04122e0$6801a8c0@oemcomputer><1696498986EFEC4D9153717DA325CB7271D491@vaebe104.NOE.Nokia.com> <010301c8a634$464caf00$6801a8c0@oemcomputer> <1696498986EFEC4D9153717DA325CB727BC9D4@vaebe104.NOE.Nokia.com> Date: Wed, 30 Apr 2008 09:20:00 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc89117aa37108865fe3ff488ed888216176ea2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.90.53 Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: > To: ; > Sent: Wednesday, April 30, 2008 1:02 AM > Subject: RE: [Isms] open issues ... > Perhaps we're discovering a limitation that RFC 341x didn't really > consider: when you use pairwise secret keys, the key (and its > securityName) always identifies (at least implicitly) both ends of the > relationship. In case of public key crypto, that's not the case. My recollection was that we consciously used this property in the design of USM. I don't recall any discussions of whether the property held true for public keys. ... > > RFC 3413 section 3.4 specifies that securityName is provided > > to the notification receiver application. > > Yes.. but it's not clear whether this is always the same securityName > that was provided by the notification originator application > (identifying the receiver, used for access control on the originator > side), or a securityName identifying the originator. > > For pairwise secret keys, it doesn't matter. For public keys, if it's > important to know the former on the notification receiver side, we > might need to pass it separately from the SSH user name. The assumption when the architecture was designed was that the securityName delivered to the notification receiver application would be whatever one was supplied by the notification generator, which would be whatever was used by access control to determine whether the information should be permitted to be delivered to that party. It's *not* a securityName identifying "the originator" - the only thing in the architecture that comes close to that concept would be the snmpEngineID. Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 30 09:27:03 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE2313A69E3; Wed, 30 Apr 2008 09:27:03 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8740328C3B4 for ; Wed, 30 Apr 2008 09:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulYE243cnED5 for ; Wed, 30 Apr 2008 09:27:02 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id CA86228C3FD for ; Wed, 30 Apr 2008 09:26:53 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA09.westchester.pa.mail.comcast.net with comcast id KrfA1Z06817dt5G5901d00; Wed, 30 Apr 2008 16:24:40 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA13.westchester.pa.mail.comcast.net with comcast id KsSs1Z0034HwxpC3Z00000; Wed, 30 Apr 2008 16:26:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=0vr2hhRekoyMvwS12LgA:9 a=MTsbJ6-ggnT8xopfM_EA:7 a=NBQG6AjoqXGJNZNHi719qiTRfSoA:4 a=lZB815dzVvQA:10 a=1pxjJC3EenQA:10 a=OS7PZEPQ3MUA:10 a=XF7b4UCPwd8A:10 From: "David Harrington" To: "'Randy Presuhn'" , References: <20080422210355.GA12678@elstar.local><002401c8a4dc$869f3400$6801a8c0@oemcomputer><20080423064530.GC13183@elstar.local><000d01c8a513$af1af400$6801a8c0@oemcomputer><20080423084701.GE13273@elstar.local><000601c8a56a$e95f1c20$6801a8c0@oemcomputer><000001c8a597$b0349560$011716ac@NEWTON603><000c01c8a59a$c04122e0$6801a8c0@oemcomputer><1696498986EFEC4D9153717DA325CB7271D491@vaebe104.NOE.Nokia.com><010301c8a634$464caf00$6801a8c0@oemcomputer><1696498986EFEC4D9153717DA325CB727BC9D4@vaebe104.NOE.Nokia.com> <002d01c8aad5$a91c0180$6801a8c0@oemcomputer> Date: Wed, 30 Apr 2008 12:26:52 -0400 Message-ID: <017501c8aadf$00f5b230$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <002d01c8aad5$a91c0180$6801a8c0@oemcomputer> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Aciq3gaV5RyWX8PDT4KOyrdMKTn7FQAALfVA Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org The securityName represents the principal on whose behalf the notification was originated. So typically, this is not the host, but the identity of the "user" on whose behalf the notification is sent. **on whose behalf** was an important phrase during SNMNPv3 development. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Wednesday, April 30, 2008 11:20 AM > To: isms@ietf.org > Subject: Re: [Isms] open issues > > Hi - > > > From: > > To: ; > > Sent: Wednesday, April 30, 2008 1:02 AM > > Subject: RE: [Isms] open issues > ... > > Perhaps we're discovering a limitation that RFC 341x didn't really > > consider: when you use pairwise secret keys, the key (and its > > securityName) always identifies (at least implicitly) both > ends of the > > relationship. In case of public key crypto, that's not the case. > > My recollection was that we consciously used this property in > the design > of USM. I don't recall any discussions of whether the > property held true for > public keys. > > ... > > > RFC 3413 section 3.4 specifies that securityName is provided > > > to the notification receiver application. > > > > Yes.. but it's not clear whether this is always the same > securityName > > that was provided by the notification originator application > > (identifying the receiver, used for access control on the originator > > side), or a securityName identifying the originator. > > > > For pairwise secret keys, it doesn't matter. For public > keys, if it's > > important to know the former on the notification receiver side, we > > might need to pass it separately from the SSH user name. > > The assumption when the architecture was designed was that the > securityName delivered to the notification receiver application would > be whatever one was supplied by the notification generator, > which would > be whatever was used by access control to determine whether > the information > should be permitted to be delivered to that party. It's > *not* a securityName > identifying "the originator" - the only thing in the > architecture that comes close > to that concept would be the snmpEngineID. > > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 30 09:33:19 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35193A6E43; Wed, 30 Apr 2008 09:33:19 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D433A6E43 for ; Wed, 30 Apr 2008 09:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.846 X-Spam-Level: X-Spam-Status: No, score=-5.846 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nylNXe6DfNp for ; Wed, 30 Apr 2008 09:33:17 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8709B3A6B8E for ; Wed, 30 Apr 2008 09:33:17 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 30 Apr 2008 09:33:20 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m3UGXK30019872; Wed, 30 Apr 2008 09:33:20 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3UGXK5O008145; Wed, 30 Apr 2008 16:33:20 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Apr 2008 09:33:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Apr 2008 09:34:10 -0700 Message-ID: In-Reply-To: <002d01c8aad5$a91c0180$6801a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isms] open issues Thread-Index: Aciq3jHsIEG/dufQTmSvMiCy1s7rOQAAPceA References: <20080422210355.GA12678@elstar.local><002401c8a4dc$869f3400$6801a8c0@oemcomputer><20080423064530.GC13183@elstar.local><000d01c8a513$af1af400$6801a8c0@oemcomputer><20080423084701.GE13273@elstar.local><000601c8a56a$e95f1c20$6801a8c0@oemcomputer><000001c8a597$b0349560$011716ac@NEWTON603><000c01c8a59a$c04122e0$6801a8c0@oemcomputer><1696498986EFEC4D9153717DA325CB7271D491@vaebe104.NOE.Nokia.com><010301c8a634$464caf00$6801a8c0@oemcomputer><1696498986EFEC4D9153717DA325CB727BC9D4@vaebe104.NOE.Nokia.com> <002d01c8aad5$a91c0180$6801a8c0@oemcomputer> From: "Joseph Salowey (jsalowey)" To: "Randy Presuhn" , X-OriginalArrivalTime: 30 Apr 2008 16:33:20.0350 (UTC) FILETIME=[E69C6FE0:01C8AADF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2824; t=1209573200; x=1210437200; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Isms]=20open=20issues |Sender:=20; bh=Q50l7Aa2mP8i4cgtTxl2dFRLTmihXYS92QRp7KNEzvE=; b=eH+m2rlJtjxQZ2NxV275d/+3dQS7UUYTTxHAnsHmpe/iUHz7tVwIu1jjCa R4d4belbXNHYSOHATBvZuqfigNRZU+5Vu858bV21/bZzarCi9V6P30ohtFpZ xtp4UdHk2Z8XwUz7OZDWdJ5SEcxO897bhOkWQ1sFUPU/4Ue0vkbKI=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Wednesday, April 30, 2008 8:20 AM > To: isms@ietf.org > Subject: Re: [Isms] open issues > > Hi - > > > From: > > To: ; > > Sent: Wednesday, April 30, 2008 1:02 AM > > Subject: RE: [Isms] open issues > ... > > Perhaps we're discovering a limitation that RFC 341x didn't really > > consider: when you use pairwise secret keys, the key (and its > > securityName) always identifies (at least implicitly) both > ends of the > > relationship. In case of public key crypto, that's not the case. > > My recollection was that we consciously used this property in > the design of USM. I don't recall any discussions of whether > the property held true for public keys. > [Joe] USM key localization changes this a bit in that the key that is used depends upon both the security name and Engine ID. I don't think that this is explicitly part of the architecture, but it does creep into to how one deals with the security issues. > ... > > > RFC 3413 section 3.4 specifies that securityName is > provided to the > > > notification receiver application. > > > > Yes.. but it's not clear whether this is always the same > securityName > > that was provided by the notification originator application > > (identifying the receiver, used for access control on the > originator > > side), or a securityName identifying the originator. > > > > For pairwise secret keys, it doesn't matter. For public > keys, if it's > > important to know the former on the notification receiver side, we > > might need to pass it separately from the SSH user name. > > The assumption when the architecture was designed was that > the securityName delivered to the notification receiver > application would be whatever one was supplied by the > notification generator, which would be whatever was used by > access control to determine whether the information should be > permitted to be delivered to that party. It's *not* a > securityName identifying "the originator" - the only thing in > the architecture that comes close to that concept would be > the snmpEngineID. > [Joe] When considering authorization for delivering notifications you want to authorize the identity of the recipient of the notification. In USM this corresponds to the one holding the key associated with the security name that can decrypt the message upon reception. > Randy > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 30 09:34:12 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B44B28C286; Wed, 30 Apr 2008 09:34:12 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D60B3A6E66 for ; Wed, 30 Apr 2008 09:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMaKyox2ZjSc for ; Wed, 30 Apr 2008 09:34:09 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 56D8B3A6A98 for ; Wed, 30 Apr 2008 09:34:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=h9+iQY2OBfCpnJIFVNj+BYSYIyNRKk/6ObhCo23LqMhyu4GrA7QVj1p1mn3coKEB; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.90.53] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1JrFFz-0000mV-VA for isms@ietf.org; Wed, 30 Apr 2008 12:34:12 -0400 Message-ID: <004a01c8aad7$ae898dc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20080422210355.GA12678@elstar.local><002401c8a4dc$869f3400$6801a8c0@oemcomputer><20080423064530.GC13183@elstar.local><000d01c8a513$af1af400$6801a8c0@oemcomputer><20080423084701.GE13273@elstar.local><000601c8a56a$e95f1c20$6801a8c0@oemcomputer><000001c8a597$b0349560$011716ac@NEWTON603><000c01c8a59a$c04122e0$6801a8c0@oemcomputer><1696498986EFEC4D9153717DA325CB7271D491@vaebe104.NOE.Nokia.com><010301c8a634$464caf00$6801a8c0@oemcomputer><1696498986EFEC4D9153717DA325CB727BC9D4@vaebe104.NOE.Nokia.com> <002d01c8aad5$a91c0180$6801a8c0@oemcomputer> <017501c8aadf$00f5b230$0600a8c0@china.huawei.com> Date: Wed, 30 Apr 2008 09:34:29 -0600 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8885d2a9c731cc891173b28c2880dddbb2d9b7bc31d78914927350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.90.53 Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org Hi - > From: "David Harrington" > To: "'Randy Presuhn'" ; > Sent: Wednesday, April 30, 2008 10:26 AM > Subject: RE: [Isms] open issues > > The securityName represents the principal on whose behalf the > notification was originated. So typically, this is not the host, but > the identity of the "user" on whose behalf the notification is sent. > > **on whose behalf** was an important phrase during SNMNPv3 > development. ... Yes. And in the case of the notification originator, it isn't necessarily the same string as the securityName used by the subscriber, even though that's probably the most common case. (The reason for making it different is if one is extremely paranoid about the possibility of compromised systems being used to generate phony notification streams puporting to come from some other system.) But even in that case, this other securityName is still conceptually used to identify (as an alias, if you will) the user on whose behalf the information is being sent. Randy _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Apr 30 09:45:38 2008 Return-Path: X-Original-To: isms-archive@megatron.ietf.org Delivered-To: ietfarch-isms-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AA1B3A6EC5; Wed, 30 Apr 2008 09:45:38 -0700 (PDT) X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00E23A6EA5 for ; Wed, 30 Apr 2008 09:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9kHnwr+8Hj2 for ; Wed, 30 Apr 2008 09:45:36 -0700 (PDT) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id B84513A6DDA for ; Wed, 30 Apr 2008 09:45:35 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA06.westchester.pa.mail.comcast.net with comcast id Krry1Z0070SCNGk560AT00; Wed, 30 Apr 2008 16:45:23 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA09.westchester.pa.mail.comcast.net with comcast id Ksla1Z00K4HwxpC3V00000; Wed, 30 Apr 2008 16:45:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=3DMGixvvYdAWnNf9X6IA:9 a=aHI3FMyPs_f0xSdRqm4A:7 a=Da6oHEG9JJlcsUC7quiBXKGckawA:4 a=lZB815dzVvQA:10 a=1pxjJC3EenQA:10 a=OS7PZEPQ3MUA:10 a=5WZzfXpOq_gA:10 From: "David Harrington" To: "'Joseph Salowey \(jsalowey\)'" , "'Randy Presuhn'" , References: <20080422210355.GA12678@elstar.local><002401c8a4dc$869f3400$6801a8c0@oemcomputer><20080423064530.GC13183@elstar.local><000d01c8a513$af1af400$6801a8c0@oemcomputer><20080423084701.GE13273@elstar.local><000601c8a56a$e95f1c20$6801a8c0@oemcomputer><000001c8a597$b0349560$011716ac@NEWTON603><000c01c8a59a$c04122e0$6801a8c0@oemcomputer><1696498986EFEC4D9153717DA325CB7271D491@vaebe104.NOE.Nokia.com><010301c8a634$464caf00$6801a8c0@oemcomputer><1696498986EFEC4D9153717DA325CB727BC9D4@vaebe104.NOE.Nokia.com><002d01c8aad5$a91c0180$6801a8c0@oemcomputer> Date: Wed, 30 Apr 2008 12:45:34 -0400 Message-ID: <017601c8aae1$9e4848c0$0600a8c0@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.3198 Thread-Index: Aciq3jHsIEG/dufQTmSvMiCy1s7rOQAAPceAAABk5eA= Subject: Re: [Isms] open issues X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org In SNMPv3, we mixed things up fairly well. I think the two things we wanted to achive are 1) determine whether the receiver is authorized to receive the data in the notification (i.e. whether to send the notificastion), and 2) the receiver wants to authenticate the message as being from the right engineID, the right principal, within the allowed time window, and integrity-checked, encrypted (if called for), etc. Since we only dealt with symmetric protocols, we allowed the assumption to leak in that one securityName worked for both purposes. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Joseph Salowey (jsalowey) > Sent: Wednesday, April 30, 2008 12:34 PM > To: Randy Presuhn; isms@ietf.org > Subject: Re: [Isms] open issues > > > > > -----Original Message----- > > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > > Behalf Of Randy Presuhn > > Sent: Wednesday, April 30, 2008 8:20 AM > > To: isms@ietf.org > > Subject: Re: [Isms] open issues > > > > Hi - > > > > > From: > > > To: ; > > > Sent: Wednesday, April 30, 2008 1:02 AM > > > Subject: RE: [Isms] open issues > > ... > > > Perhaps we're discovering a limitation that RFC 341x didn't really > > > consider: when you use pairwise secret keys, the key (and its > > > securityName) always identifies (at least implicitly) both > > ends of the > > > relationship. In case of public key crypto, that's not the case. > > > > My recollection was that we consciously used this property in > > the design of USM. I don't recall any discussions of whether > > the property held true for public keys. > > > [Joe] USM key localization changes this a bit in that the key that is > used depends upon both the security name and Engine ID. I don't think > that this is explicitly part of the architecture, but it does > creep into > to how one deals with the security issues. > > > ... > > > > RFC 3413 section 3.4 specifies that securityName is > > provided to the > > > > notification receiver application. > > > > > > Yes.. but it's not clear whether this is always the same > > securityName > > > that was provided by the notification originator application > > > (identifying the receiver, used for access control on the > > originator > > > side), or a securityName identifying the originator. > > > > > > For pairwise secret keys, it doesn't matter. For public > > keys, if it's > > > important to know the former on the notification receiver > side, we > > > might need to pass it separately from the SSH user name. > > > > The assumption when the architecture was designed was that > > the securityName delivered to the notification receiver > > application would be whatever one was supplied by the > > notification generator, which would be whatever was used by > > access control to determine whether the information should be > > permitted to be delivered to that party. It's *not* a > > securityName identifying "the originator" - the only thing in > > the architecture that comes close to that concept would be > > the snmpEngineID. > > > [Joe] When considering authorization for delivering notifications you > want to authorize the identity of the recipient of the > notification. In > USM this corresponds to the one holding the key associated with the > security name that can decrypt the message upon reception. > > > Randy > > > > _______________________________________________ > > Isms mailing list > > Isms@ietf.org > > https://www.ietf.org/mailman/listinfo/isms > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@ietf.org https://www.ietf.org/mailman/listinfo/isms