From root@core3.amsl.com Tue May 4 22:30:33 2010 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7A99B3A6B12; Tue, 4 May 2010 22:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100505053023.7A99B3A6B12@core3.amsl.com> Date: Tue, 4 May 2010 22:30:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-dtls-tm-11.txt 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: , X-List-Received-Date: Wed, 05 May 2010 05:30:33 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) Author(s) : W. Hardaker Filename : draft-ietf-isms-dtls-tm-11.txt Pages : 64 Date : 2010-05-04 This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This transport model is designed to meet the security and operational needs of network administrators. It supports sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g. UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the TLS Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-dtls-tm-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-04222928.I-D@ietf.org> --NextPart-- From wjhns1@hardakers.net Tue May 4 22:35:44 2010 Return-Path: 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 0402A28C16E; Tue, 4 May 2010 22:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 NVwMbeI677NM; Tue, 4 May 2010 22:35:43 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 824753A6AD1; Tue, 4 May 2010 22:33:17 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id CEC0C9826D; Tue, 4 May 2010 22:33:03 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Tue, 04 May 2010 22:33:03 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: iesg@ietf.org Subject: [Isms] New draft-ietf-isms-dtls-tm-11.txt posted 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: , X-List-Received-Date: Wed, 05 May 2010 05:35:44 -0000 FYI, I've posted a new copy of the draft-ietf-isms-dtls-tm that addresses the concerns and comments brought forth by the IESG during their review. Since this document is currently slated to be discussed on the 6th I wanted to get a fresh copy out before that time. I'll post a list of discusses and comments received and the changes that resulted from them to the WG list tomorrow. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed May 5 13:35:00 2010 Return-Path: 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 27A333A6CA1; Wed, 5 May 2010 13:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-1.481, BAYES_40=-0.185, FM_ASCII_ART_SPACINGc=0.833] 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 DpUELta0AfXw; Wed, 5 May 2010 13:34:54 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id BB5F83A6ABF; Wed, 5 May 2010 13:34:51 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 28E73981F1; Wed, 5 May 2010 13:34:38 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Wed, 05 May 2010 13:34:37 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: iesg@ietf.org Subject: [Isms] Status of IESG-review changes for draft-ietf-isms-dtls-tm 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: , X-List-Received-Date: Wed, 05 May 2010 20:35:00 -0000 Enclosed is a very long document describing in detail exactly where all the outstanding items are (in my view) with respect to the IESG member comment and discuss topics. I've updated my marking list a bit to reflect who's got the current ball on a given topic. Responses from each person involved in the discussion are prefixed with their name. Outstanding marks I'm waiting actively to hear back on: DISCUSS: The state is still considered in "discussion" (regardless of whether it's an IESG DISCUSS or COMMENT) Marks that I consider "will assume closed at some point if they don't respond with additional problems based on the proposed resolution. DONE: The suggestion/issue was acted on and the changes are described WONTDO: Nothing was done; refer to the WH: response for reasons why I'm proposing nothing be done. ANSWERED: A question was answered but had no action resulting from it. Marks that indicate formal closure because the commenting party has indicated all is well for the given topic: CLOSED: Affirmation has been received that the results are good. (in some cases when a direct suggestion was followed verbatim this mark was applied as a response really isn't needed) Most of the CLOSED/DONE changes have been already placed in the updated -11 document, though there are a few changes locally that were done after -11 was published yesterday. IESG DISCUSS and COMMENT Review =============================== Date: 2010-05-05 13:23:35 PDT Table of Contents ================= 1 David Harrington DISCUSS and COMMENTS 1.1 Discuss Items 1.1.1 3.1.1, 4. Per RFC3365 (BCP61), 1.1.2 4.1.1 "Enterprise configurations are encouraged" 1.1.3 4.4.1.1 3rd para., "the tmSecurityName is presented to the 1.1.4 5.1.1 "If demultiplexing ..." Should this be strengthened? 1.1.5 5.2 4) "an implementation SHOULD ... an implementation MAY 1.1.6 5.4 4) Why SHOULD instead of MUST? What circumstances make 1.1.7 6. The MIB is included in the document to make it 1.1.8 MIB related issues 1.1.9 SnmpTLSAddress - "This textual convention SHOULD NOT be used 1.1.10 Fingerprint - should this be SnmpTLSFingerprint, to be 1.1.11 SnmpTlstmCertSANDNSName - will the requirement to use 1.1.12 SnmpTlstmCertSANiPAddress - the IPv6 support for this 1.1.13 snmpTlstmCertToTSNTable - "... then additional rows MUST 1.1.14 snmpTlstmCertToTSNTable and snmpTlstmCertToTSNMapType - It 1.1.15 snmpTlstmCertToTSNTable - the example text in the paragraph 1.1.16 snmpTlstmCertToTSNTable - Commonname field is 1.1.17 snmpTlstmCertToTSNData - what is this? there is no 1.1.18 8.1 "Implementations SHOULD limit the lifetime ..." Can you 1.1.19 8.3 I found this difficult to understand. The "default 1.1.20 9.2 I think this section does not describe the implications 1.1.21 10 IANA Considerations: 1.2 Comments: 1.2.1 section 1: s/standard defined/specification/ 1.2.2 section 3: ist paragraph, second sentence - I had trouble 1.2.3 3.1.2 last sentence, s/should/SHOULD/ 1.2.4 4.1.0 s/are are/are/ 1.2.5 4.3.1 s/Outgoing message field/Outgoing message/ 1.2.6 4.3.2 s/Incoming message field/Incoming message/ 1.2.7 4.3.1 tmState (first usage - a reference?) 1.2.8 4.3.2 incomingMessage: I found this sentence hard to 1.2.9 4.4.1.1 s/through an TLSTM session/through a single TSLTM 1.2.10 SnmpTLSAddress - references rfc3986 and 5246 are never 1.2.11 snmpTlstmCertToTSNTable - instead of an example of 1.2.12 11. s/defined by David Harrington/documented by David Harrington/ 1.2.13 The Appendix is too verbose 2 Dan Romascanu DISCUSS from IESG 2.1 Discuss Items: 2.1.1 1. There are a number of objects in the MIB module with a 2.1.2 2. I could not make sense what section 9.2 tries to 2.1.3 3. I know that the paragraph starting with 'Further, 2.2 Comments: 2.2.1 1. For consistency purposes (as TLS is expanded) expand 2.2.2 2. In a couple of places (section 1, section 9.1) I 2.2.3 3. In Section 3.3 2.2.4 4. In Section 4.1 2.2.5 5. In Section 5.2 5b) s/If there is not a corresponding 2.2.6 6. In Section 5.4.4 2.2.7 7. Some of the references in the MIB module are not 3 Alexey Melnikov : 3.1 Discuss: 3.1.1 1) In Section 7: 3.1.2 2) In Section 7: 3.1.3 3) In Section 7: 3.1.4 4) In Section 7: 3.1.5 5). 3.2 Comment: 3.2.1 In Section 3.1.2, the last sentence of the last paragraph: 3.2.2 3.1.3. (D)TLS Connections 3.2.3 In Section 5.1.1: 3.2.4 In Section 7: 3.2.5 Also in Section 7: 3.2.6 8.1. Sessions 4 Peter Saint-Andre 4.1 Discuss: 4.1.1 The definition of snmpTlstmCertSANIpAddress mentions that 4.1.2 The definition of SnmpTLSAddress states that 4.2 Comment: 4.2.1 Section 1.1 has: 4.2.2 I realize that RFC 3411 talks about "privacy", but the 4.2.3 Forgive my ignorance regarding SNMP/SMI, but I can't seem 4.2.4 The definition of snmpTlstmCertSANDNSName mentions 4.2.5 Is there any provision for supporting subjectAltName 4.2.6 Is there a preferred order of matching subjectAltName 4.2.7 How exactly does an entity prepare for matching of 4.2.8 It might be appropriate for this specification to say 5 Tim Polk 5.1 RFC 5590 states: 5.2 The document requires use of TLS, and mandates 1 David Harrington DISCUSS and COMMENTS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1.1 Discuss Items ======================= 1.1.1 CLOSED 3.1.1, 4. Per RFC3365 (BCP61), -------------------------------------------- However security must be a MUST IMPLEMENT so that end users will have the option of enabling it when the situation calls for it. OLD: "A TLS Transport Model implementation SHOULD support message encryption to protect sensitive data from eavesdropping attacks." NEW: "A TLS Transport Model implementation MUST support message encryption to allow users to protect sensitive data from eavesdropping attacks." + WH: I'm actually fine with this, and someone else had a similar comment. But the original USM had a goal of not requiring encryption and thus I tried to carry that forward. I'll change it to a "MUST support" but I'll note that you referenced RFC3365, but actually RFC3365 specifically says you don't need to necessarily require encryption if it's not needed and I can envision SNMP implementations that don't need encryption for the data the CR or NG may be distributing. I.E., SNMP certainly can carry sensitive information that should not be disclosed, but I don't know that we require all usages of the protocol to carry such information. Certainly most probably do, however. + WH: Never heard directly back, but since I took his text I'm assuming this is resolved. 1.1.2 DONE 4.1.1 "Enterprise configurations are encouraged" ------------------------------------------------------------ Why enterprises specifically? This purpose of this text is to encourage the use of subjectAltName in preference to other alterantives, right? Could this be strengthened to a SHOULD or RECOMMENDED to promote a common interoperable configuration? + WH: Enterprise wasn't the right word, you're right. I've changed the text to: Deployments SHOULD map the "subjectAltName" component of X.509 certificates to the TLSTM specific tmSecurityNames. 1.1.3 DONE 4.4.1.1 3rd para., "the tmSecurityName is presented to the ---------------------------------------------------------------------- TLS Transport Model by the application" is inaccurate; securityName (possibly from snmpTargetParamsSecurityname) is presented by the application to the Security Model, which transforms the securityName into a tmSecurityname. An application should have no access to tmState. I am a bit uneasy with the wording that says "The securityName MAY be derived ... and MAY be used ..." This looks like it is making the behavior optional. I recommend "Transport-model-aware security models derive tmSecurityName from a securityName, possibly configured in MIB modules for notifications and access controls. Transport models SHOULD use predictable tmSecurityNames ..."; I debated whether this should be a comment or a DISCUSS, but decided on DISCUSS because I think it is important to make clear the "MAY" behavior is well-specified in models designed for interoperability. + WH: All of the above text is functionally a copy with slight modifications (SSH -> TLS) from section 4.1.1 of RFC5592, which you authored. I find it amusing that you're marking the text you wrote in 5592 as a DISCUSS! More seriously, I think cleaning up the text is fine. In general I tried to copy text from 5592 for consistency between the documents. How about this (your text was used for the second paragraph): On the (D)TLS client side of a connection the tmSecurityName is presented to the TLS Transport Model by the Security Model. The Security Model likely derived the tmSecurityName from the securityName presented to the Security Model by the application (possibly because of configuration specified in the SNMP-TARGET-MIB). Transport-model-aware security models derive tmSecurityName from a securityName, possibly configured in MIB modules for notifications and access controls. Transport Models SHOULD use predictable tmSecurityNames so operators will know what to use when configuring MIB modules that use securityNames derived from tmSecurityNames. The TLSTM generates predictable tmSecurityNames based on the configuration found in the SNMP-TLS-TM-MIB's snmpTlstmCertToTSNTable and relies on the network operators to have configured this table appropriately. 1.1.4 WONTDO 5.1.1 "If demultiplexing ..." Should this be strengthened? ------------------------------------------------------------------------ "MUST implement if DTLS implementation does not provide. If the implementation is, say, a toolkit, and it is unknown whether the DTLS implementation it will be used with does provide demultiplexing, then it is MUST implement, but the demultiplexing function in the implementation SHOULD be able to be bypassed by a subsequent implementer if the DTLS provides demultiplexing." + WH: I don't think that it's appropriate for us to dive into the various different ways that a SNMP implementation may need to get involved with a TLS implementation. I think that's way too deep to be recommending things. All we should be saying is that if you're going the route of doing it in the SNMP stack, use these steps. I don't think it's appropriate for us to dictate how they make the decision about where to put the demultiplexing as it may depend on many stack issues that we can't possibly enumerate or predict. 1.1.5 ANSWERED 5.2 4) "an implementation SHOULD ... an implementation MAY -------------------------------------------------------------------------- return a snmpTlstmSessionNoSessions" - when is it appropriate to not follow the SHOULD? Why do we need the extra complexity of this option? Why not just make it a MUST so all implementatioins behave in the same way? + WH: I believe there may be implementations where internally to that particular point in the code it may not be possible to open a new transport connection. Specifically, I'm not positive it's safe to assume that a connection can be opened that can modify or access connection parameters that may be stored in a data structure higher up in the calling stack that isn't accessible in the lower-level code that is actually trying to send out an outgoing packet. I know in Net-SNMP this actually looked like it might be a problem, in fact, given the currently defined (and published and thus non-modifiable) API. We've actually worked around it but I'm not sure every stack could. It all depends on how the API works between the various levels of stack. It becomes rather implementation dependent as to whether you can open a new connection when you've noticed that an existing one is no longer usable. 1.1.6 DONE 5.4 4) Why SHOULD instead of MUST? What circumstances make ---------------------------------------------------------------------- this acceptable? Why not make the behavior consistent across implementations with a MUST? + WH: I was worried there would be cases where it wouldn't be possible. But since I can't think any, I'll assume that there aren't any. I've changed it to a MUST. Turns out RFC5246 actually indicates a MUST as well. 1.1.7 DONE 6. The MIB is included in the document to make it ------------------------------------------------------------- SNMP-manageable, but then there are places, like 6.3, that say "can be used"; Is the MIB mandatory-to-implement for compliance? It doesn't seem to say that explicitly. I recommend tightening the text that says things like implementers "can". + WH: The "can" was meant to indicate that a management station "can" use them, but you're right the wording isn't clear in that regard. I've reworded to: The SNMP-TLS-TM-MIB defines counters that provide network management stations with information about session usage and potential errors that a MIB-instrumented device may be experiencing. 1.1.8 TODO MIB related issues ------------------------------ 1.1.9 WONTDO SnmpTLSAddress - "This textual convention SHOULD NOT be used -------------------------------------------------------------------------- directly in object definitions since it restricts addresses to a specific format. However, if it is used it MAY be used either on its own or ..." I'm a MIB Doctor and I don't understand what this is talking about. I could not provide advice to an implementer or future MIB writer interpreting this text. I don't understand why a textual convention that restricts the format SHOULD NOT be used - isn't that the purpose of a TC - to refine the semantics and/or the format? And if it is SHOULD NOT, why do we follow that with a MAY that really doesn't discuss the circumstances when ignoring the SHOULD NOT is appropriate. + WH: That's another example of text that comes directly from the text you wrote in RFC5592 with no modifications at all. Looking further, though, I find that you copied it directly from the objects in the TRANSPORT-ADDRESS-MIB. I believe the goal of the wording was to say that the address TCs should not be used directly in a MIB but instead a pair of generic TDomain and the generic TAddress objects should be used instead. IE, don't do this: snmpFooBarAddress OBJECT-TYPE SYNTAX SnmpTLSAddress but instead do: snmpFooBarDomain OBJECT-TYPE SYNTAX TDomain snmpFooBarAddress OBJECT-TYPE SYNTAX TAddress So... I'm not sure what to do with this. I'm going to mark it as WONTDO unless you come up with text you'd like to replace it with. Sound good? 1.1.10 CLOSED Fingerprint - should this be SnmpTLSFingerprint, to be --------------------------------------------------------------------- consistent with RFC4181 naming conventions? + WH: The object was originally designed to be used generically but was then later TLSized but the name was never made specific again. Changed. + WH: Never heard directly back, but since I took his text I'm assuming this is resolved. 1.1.11 ANSWERED SnmpTlstmCertSANDNSName - will the requirement to use ---------------------------------------------------------------------- lowercase be problematic re: newPrep? + WH: the subjectAltName dNSName is defined to be case-insensitive so you must compare it in a case insensitive way thus we need to deal with it on the mapping side to ensure that no matter what case mix is put into the certificate value it maps to the same securityName + Alexey Melnikov : Hi David, I am agreeing with many of the points you raised in your DISCUSS, but I would like to comment on one which I think it incorrect: David Harrington wrote: >SnmpTlstmCertSANDNSName - will the requirement to use lowercase be problematic re: newPrep? > > The document defines snmpTlstmCertSANDNSName as: snmpTlstmCertSANDNSName OBJECT-IDENTITY STATUS current DESCRIPTION "Maps a subjectAltName's dNSName to a tmSecurityName after first converting it to all lower case." ::= { snmpTlstmCertToTSNMIdentities 3 } Due to character restriction on subjectAltName's dNSName, it can't contain Internationalized (non-US-ASCII) domains. So this is not an issue. 1.1.12 CLOSED SnmpTlstmCertSANiPAddress - the IPv6 support for this -------------------------------------------------------------------- object and the TSM prefix feature are impossible to use together in combination with the mandatory-to-implement VACM. Yet no recommendation is made about which is the feature to be preferred, or how to make such a decision. If I remember correctly, the enable/disable for the TSM prefix feature would apply to ALL transport models, not just TLSTM. I think there should be text, probably in the Security Considerations or Operations Considerations that discuss the implications and tradeoffs for SNMP security if the ipAddress field is used in an IPv6 environment, or the prefix feature is disabled to permit IPv6 ipAddress field authentication, and what to watch for in terms of VACM errors if both ipAddress authentication and TSM prefixing are enabled. + WH: How about something like the following new section in the operational considerations: 8.5. IPv6 and securityName mapping when used with TSM and VACM It is possible to create a condition where it is impossible to map a subjectAltName to a securityName when all of the following conditions are true: o The snmpTlstmCertToTSNMapType object of a snmpTlstmCertToTSNEntry is set to the snmpTlstmCertSANIpAddress identity value. o The X.509 certificate presented by the client contains a subjectAltName with an IPv6 address in it. o The security model in use is the Transport Security Model. o The snmpTsmConfigurationUsePrefix object in the SNMP-TSM-MIB is set to 'true'. o The View-based Access Control Model is being used to authorize requests. If all of these conditions are true then the length of the generated tmSecurityName will always be 32 octet characters and the securityName generated by the TSM will be at least 36, which is longer than the length allowed by the VACM. Thus, the use of IPv6 subjectAltName to tmSecurityName mapping is NOT RECOMMENDED when snmpTsmConfigurationUsePrefix is set to true. + David H: I recommend something a bit more succinct than your proposed section 8.5: "The standard VACM access control model constrains securityNames to be 32 octets or less in length. A TLSTM generated tmSecurityName, possibly in combination with a messaging or security model that increases the length of the securityName, might cause the securityName length to exceed 32 octets. For example, a 32 octet tmSecurityName derived from an IPv6 address, paired with a TSM prefix, will generate a 36 octet securityName. Such a securityName will not be able to be used with standard VACM or TARGET MIB modules. Operators should be careful to select algorithms and subjectAltNames to avoid this situation." This might be best in section 4.1 where there is already a discussion of generation of tmSecurityName and subsequent mapping into securityName used in MIB modules. I recommend placing such advice after the paragraph that starts "This tmSecurityName may be later translated". This would satisfy my concerns. (Your original text made it seem like the easy solution was to not use VACM.) Does this work for you? + WH: I think that's fine too and have done as you've described. + WH: Never heard directly back, but since I took his text I'm assuming this is resolved. 1.1.13 DONE snmpTlstmCertToTSNTable - "... then additional rows MUST --------------------------------------------------------------------- be searched ..." I think SecCons [Ed: security considerations] should discuss whether this could be used by DoS attacks. + WH: I added the following sentence to the security consideration section that discusses the snmpTlstmCertToTSNTable: When this table contains a significant number of rows it may affect the system performance when accepting new (D)TLS connections. Note that I suspect it'd take a lot of rows to check before it would surpass the length of time it takes to verify the certificate cryptographically. 1.1.14 DONE snmpTlstmCertToTSNTable and snmpTlstmCertToTSNMapType - It ----------------------------------------------------------------------- is unclear what the next steps are if a) an entry is found that violates the VACM length requirement, and b) no other matching entry is found. + WH: I've addressed this with a few changes: 1. Modification to the "accepting a session" section text so the new sentence reads: If the session can not be opened for any reason at all, including cryptographic verification failures +++and snmpTlstmCertToTSNTable lookup failures+++, then the snmpTlstmSessionOpenErrors counter is incremented and processing stops. 2. In the snmpTlstmCertToTSNTable text a new paragraph was added (after the "once a matching row has been found" paragraph): If no matching and valid row can be found, the connection MUST be closed and SNMP messages MUST NOT be accepted over it. (the previous paragraph already discusses that VACM requirements may dictate that future rows are searched). 1.1.15 DONE snmpTlstmCertToTSNTable - the example text in the paragraph ------------------------------------------------------------------------ "Missing values ..." is unclear and ambiguous. "may legally contain only two rows" makes it seem that the table MUST have two and only two rows. Persoanlly, I don't think readers need an example with two non-consecutive indices; that's normal SNMP. + WH: This is a duplicate of your other comment below in your "comments" section. The text was revised based on your suggestions below, so I'll refer you to those and if you have further issues here that aren't addressed by the other changes please let me know. 1.1.16 ANSWERED snmpTlstmCertToTSNTable - Commonname field is -------------------------------------------------------------- deprecated. Should we be writing support for it into new standards? + WH: Deprecated but still in very very very heavy use. In fact (IMO), it's still the most commonly used form of identifying the subject of a certificate. Yes we hope to have subjectAltName's take over most of that role but until it does we need to support using those certificates. 1.1.17 DISCUSS snmpTlstmCertToTSNData - what is this? there is no ------------------------------------------------------------------ description here of what this fields contains other than "auxiliary data" - so is this an OPAQUE value? SMIv2 deliberately obsoletes the OPAQUE data type because it fostered non-interoperable implementaitons; why are we defining opaque fields here? If a vendor wants an opaque, proprietary field that is MIB-accessible, let them put it into a vendor MIB extension. We don't need it specified (opaquely) in the standard. If there is real justification for standardization, then at least provide an example of what it is and how it will be used. And please include why the value is not necessary for some rows, but it MUST be set before modifying the RowStatus, and is in a mandatory-to-implement OBJECT-GROUP? I think MUST be ignored should be strengthened to MUST NOT be used except for a standardized purpose (to prevent implementers from deicindg to use it for something totally different that could cause interoperability problems later). This object is just way underspecified as to its purpose. + WH: If you re-read the description of the "snmpTlstmCertSpecified" object identity you'll find it is used elsewhere in the MIB. It's not a vendor specific extension, it's a generic parameter extension mechanism that may be needed for certain mapping types. This object is the direct result of a WG discussion that occurred in Sweden (I'm pretty sure) and it was decided that this route was better than the other alternatives discussed that day. In particular, Jeff H. brought up the details of a to-be-standardized-in-the-future otherName mapping that would require a parameter as well. Does this already-documented mapping (snmpTlstmCertSpecified) meet your requirement for an example, or did you want an example in the text itself. There is also an example in appendix A for using it but the interesting thing is that the example text used the old object name and no one has caught that to date. So if nothing else, thanks for making me catch that! I've double checked that the rest of the objects in the appendix match the current text. The object clearly states that the value is used by the mapping type specified via the snmpTlstmCertToTSNMapType (be a standards based mapping or a enterprise extension). Given that I'm not sure what MUST NOT clause you're wanting to insert. If you have text, please supply it as I can't extract it from your problem description. It's in the mandatory to implement object group because the directly specified securityName mapping was one the working group considered to be important and it is needed to fulfill that mapping objective. 1.1.18 ANSWERED 8.1 "Implementations SHOULD limit the lifetime ..." Can you ---------------------------------------------------------------------------- provide a reasonable default lifetime? + WH: generally the security area has shied away from recommending lifetimes in fixed documents since it's both hardware dependent, cryptographic algorithm dependent and timeline-of-the-world dependent. So the answer is "no". It's likely implementation and/or deployment dependent. 1.1.19 DONE 8.3 I found this difficult to understand. The "default ------------------------------------------------------------------- contextEngineID" is a self-identifying value that matches snmpEngineID from the SNMP-FRAMEWORK-MIB(?). The securityEngineID that you mention is the engineID for a remote target. I don't think there is a default value for a remote target. RFC3411 says that the value of a remote engineID is determined in an implementation-dependent manner. Since RFC5434 updates the SNMP architecture defined in RFC3411, I think it would be appropriate to RECOMMEND (much more strongly than the current text) using RFC5343 to perform snmpEngineID discovery that is independent of the messaging, security, and transport models. I strongly recommend using the much-clearer text from the abstract of RFC5343: The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity. [RFC5343] introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects. I would add: Implementations SHOULD provide RFC5343 support for engineID discovery. + WH: does the following text work for you? I'm not sure we needed the last line of the above paragraphs so I removed it. SNMPv3 requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity. introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. Implementations are RECOMMENDED to support and use the contextEngineID discovery mechanism defined in . 1.1.20 DONE 9.2 I think this section does not describe the implications ------------------------------------------------------------------------ of using TLSTM with an SNMPv1/v2c message, or specifying USM as the securityModel in an SNMPv3 message sent over (D)TLS. This section should state clearly that: Using a non-transport-aware Security Model with a secure Transport Model is NOT RECOMMENDED . and there should be a reference to RFC5590 section 7.1 which describes the reasons in detail. + WH: again, this is an identical copy (except SSH -> TLS) to what you put in RFC5592. That being said, I've added a new paragraph: Using a non-transport-aware Security Model with a secure Transport Model is NOT RECOMMENDED. See Section 7.1 for additional details on the coexistence of security-aware transports and non-transport-aware security models. 1.1.21 DONE 10 IANA Considerations: ------------------------------------ (I hate the fact we called the standard SNMPv3, but only one model within the SNMPv3 standard actually is version 3 - the SNMP message version 3; it makes things confusing). RFC3411 defines a modular approach where one model should not place dependencies on another model, or work only with another specific model. SNMPv3 is a messaging model, and TLSTM should be able to work with any messaging model. The SNMPv3 prefix in the IANA request should be just SNMP, to allow TLSTM to be used with other messaging models, such as a future SNMP messaging model version 4: s/SNMPv3-TLS/SNMP-TLS/, s/SNMPv3-DTLS/SNMP-DTLS/, etc. + WH: changed. Note that the table in question was actually from IANA originally as they reviewed the document during last call. Because there was some confusion I copied it into the document and fixed it so it made the assignments we wanted. But I've now also changed it so it doesn't have "v3" in it. 1.2 Comments: =================== 1.2.1 CLOSED section 1: s/standard defined/specification/ ---------------------------------------------------------- + WH: done as suggested. 1.2.2 CLOSED section 3: ist paragraph, second sentence - I had trouble ----------------------------------------------------------------------- parsing this. You seem to have a message passing between three things, but really you should only have two. I think you should drop "and the Transport Subsystem" + WH: I think your suggestion is the right approach and made that change. 1.2.3 CLOSED 3.1.2 last sentence, s/should/SHOULD/ --------------------------------------------------- + WH: done as suggested. 1.2.4 CLOSED 4.1.0 s/are are/are/ ---------------------------------- + WH: done as suggested. 1.2.5 CLOSED 4.3.1 s/Outgoing message field/Outgoing message/ -------------------------------------------------------------- + WH: done as suggested. 1.2.6 CLOSED 4.3.2 s/Incoming message field/Incoming message/ -------------------------------------------------------------- + WH: done as suggested. 1.2.7 DONE 4.3.1 tmState (first usage - a reference?) ------------------------------------------------------ + WH: I changed the description to: A reference used to pass model-specific and mechanism-specific parameters between the Transport Subsystem and transport-aware Security Models. Which came from RFC5590 and is the best text I found for describing the generic cache. 1.2.8 DONE 4.3.2 incomingMessage: I found this sentence hard to ---------------------------------------------------------------- parse. I could benefit from rewriting. + WH: This wording has repeatedly been a problem. How about just removing the "remove the DTLS bits" part of it since that's what keeps causing problems. How about just: The whole SNMP message after being processed by (D)TLS. 1.2.9 CLOSED 4.4.1.1 s/through an TLSTM session/through a single TSLTM ----------------------------------------------------------------------- session/ + WH: done as suggested. 1.2.10 CLOSED SnmpTLSAddress - references rfc3986 and 5246 are never --------------------------------------------------------------------- used in the description; I'm not sure why they are needed in the REFERENCE clause. + WH: removed. 1.2.11 DONE snmpTlstmCertToTSNTable - instead of an example of --------------------------------------------------------------- non-consecutive indices, I recommend advice recommending non-consecutive indices in case an admin wants insert an entry; using non-consecutive indices means they can insert a new entry into the gap between entries and won't need to renumber all following entries. + WH: changed to: It is recommended that administrators skip index values to leave room for insertion the of future rows (E.G., use values of 10 and 20 when creating initial rows). 1.2.12 CLOSED 11. s/defined by David Harrington/documented by David Harrington/ -------------------------------------------------------------------------------- + WH: done as suggested. 1.2.13 CLOSED The Appendix is too verbose ------------------------------------------ Offline David H and I had discussions about the example Appendix A being too long and verbose. We came to agreement about what is in version -11 and beyond, which is functionally the same example but with reduced verbiage surrounding it. 2 Dan Romascanu DISCUSS from IESG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2.1 Discuss Items: =========================== This is a very important and well written document, and before baloting a YES vote I would like to clarify a few issues: 2.1.1 WONTDO 1. There are a number of objects in the MIB module with a ----------------------------------------------------------------------- SYNTAX of Counter32, but there is no indication of the behavior at discontinuity, or reference to a discontinuity indicator. + WH: Last I checked it's fairly common not to require special discontinuity checks or objects when there is no reason not to use the SNMP standard mechanisms for handling discontinuity. EG, the TARGET-MIB, the sister-MIB SNMP-SSH-TM-MIB don't have special objects or special text. It's expected that managers will use the sysUpTime.0 scalar for detecting discontinuity as there isn't really a special need for these having discontinuity issues beyond what typical counters have. Is there a reason you believe this MIB and it's counters should be different than other published MIBs? + Dan: Let us put aside the 'sister-MIB', because the comment may apply to it as well. My understanding is that using the 'standard' sysUpTime.0 mechanism assumes that the process that implements the counters is the same as the process that counts sysUpTime, or the two are tightly coupled so that all events that lead to discontinuities are shared and lead to a reboot. While this is obviously true for core SNMP engine MIB modules like the TARGET-MIB I wonder and ask loud if this is true for the TLS/DTLS transport. + JS: Not necessarily a reboot - all that is needed is to reset sysUpTime when a discontinuity occurs. + DanR: Right. + JS: For those code bases I am familiar with, I think the answer is very clearly yes. The transport subsystem not only architecturally is part of an SNMP engine, also implementation wise I have not seen someone inventing a protocol between the transport model and the dispatcher in order to separate things such that they would have different discontinuity properties. For me, the transport models are clearly part of the core SNMP engine. + DanR: This was exactly the issue I was raising, and the question I was asking loud. If no different opinions or experiences are shared I would rest my case on this matter. + WH: I certainly know enough about one major SNMP stack to say that the discontinuities would always be the same because the transport system is definitely part of the rest of the code and can't be 'rebooted' (or otherwise) independently. In fact, the statistics information for the transports and the rest of the code base are all kept in the same place. For the other major SNMP stack, based on my discussions with them but not based on direct code-reading, I believe their transport system is also closely tied to the rest of their infrastructure. 2.1.2 CLOSED 2. I could not make sense what section 9.2 tries to ----------------------------------------------------------------- say. Is there a warning, describing a threat, a recommendation to not use the model with older versions of SNMP? + WH: This is actually text copied almost verbatim from RFC5592, our sister-RFC. Would adding the following sentence to the end of the paragraph make it more clear: It is RECOMMENDED that only SNMPv3 messages using the Transport Security Model (TSM) or another secure-transport aware security model be sent over the TLSTM transport. + Dan: Yes, thanks. 2.1.3 DISCUSS 3. I know that the paragraph starting with 'Further, ------------------------------------------------------------------- deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED.' is part of the security boilerplate for all MIB documents. I am wondering if this is not exactly the place to add text which in a stronger language warns that configuring with a lower version of SNMP the TLS transport model for SNMP is something not to do. + WH: I'm not sure I understand your point here. The text already recommends against anything less than SNMPv3 and already recommends secure mechanisms. NOT RECOMMENDED is already equal to SHOULD NOT and I don't think it's appropriate to switch to a MUST level requirement. Can you provide example text for what you're wishing to say, as I believe I may be missing your point? + Dan: Why do you think that in this very specific instance switching to a MUST level requirement is not appropriate? + WH: The text will fundamentally only apply to people deploying it. I certainly don't think it's appropriate to put in special access-control checks surrounding particular objects to ensure that no one is allowed to modify certain objects except with secured SNMPv3. We (or at least I) have heard of many deployment situations where the physically protected management network is utilizing SNMPv1 or SNMPv2c for the speed benefits it can offer and they don't have a security need on their management back-plane. But they may desire to configure our new tables for those cases they need their customers to be able to access counters, etc, or want to allow themselves access externally over (D)TLS. IMHO, it's not the job of the IETF to say "you MUST NOT do stupid things in the real world" or even "you MUST NOT use any management architecture different than what we envision to be best for you". It's our job to ensure that implementations *can* support secured networks in an interoperable way. 2.2 Comments: =================== 2.2.1 CLOSED 1. For consistency purposes (as TLS is expanded) expand --------------------------------------------------------------------- SNMP in the title. + WH: Expanded per request for -11 + Dan: OK 2.2.2 CLOSED 2. In a couple of places (section 1, section 9.1) I ----------------------------------------------------------------- encountered the term 'notification responder' while in all other places 'notification receiver' is used. The terms are not exactly synonims, is the inconsistency intentional? + WH: receiver is the correct term; changed! + Dan: OK. 2.2.3 CLOSED 3. In Section 3.3 ------------------------------- When configuring a (D)TLS target, the snmpTargetAddrTDomain and snmpTargetAddrTAddress parameters in snmpTargetAddrTable should be set to the snmpTLSTCPDomain or snmpDTLSUDPDomain object and an appropriate snmpTLSAddress value. When used with the SNMPv3 message processing model, the snmpTargetParamsMPModel column of the snmpTargetParamsTable should be set to a value of 3. The snmpTargetParamsSecurityName should be set to an appropriate securityName value and the snmpTlstmParamsClientFingerprint parameter of the snmpTlstmParamsTable should be set a value that refers to a locally held certificate (and the corresponding private key) to be used. All 'should' seem to need to be capitalized. + WH: I've changed all instances of "should" to "SHOULD" in that paragraph. + Dan: OK. 2.2.4 CLOSED 4. In Section 4.1 ------------------------------- Quoting the draft: Enterprise configurations are encouraged to map a "subjectAltName" component of the X.509 certificate to the TLSTM specific tmSecurityName. I do not think that we have a clear notion of what an 'enterprise configuration' is and why it would be more appropriate for such a mapping. It looks like a (non-capitalized) may is more appropriate here. + WH: David H. brought up a similar issue. I've changed the text to: Deployments SHOULD map the "subjectAltName" component of X.509 certificates to the TLSTM specific tmSecurityNames. Does this work for you? + Dan: Yes. 2.2.5 CLOSED 5. In Section 5.2 5b) s/If there is not a corresponding --------------------------------------------------------------------- LCD entry/If there is no corresponding LCD entry/ + WH: thanks; changed! + Dan: OK. 2.2.6 CLOSED 6. In Section 5.4.4 --------------------------------- 4) Have (D)TLS close the specified connection. This SHOULD include sending a close_notify TLS Alert to inform the other side that session cleanup may be performed. Unless I miss something sending the close_notify TLS Alert is always part of the closing sequence, so s/SHOULD/MUST/ + WH: Yep; David H. mentioned this as well. + Dan: OK. 2.2.7 CLOSED 7. Some of the references in the MIB module are not ----------------------------------------------------------------- included as Informative References - for example RFC 1033, RFC 3490 + WH: I've added those two references to the Informative section. + Dan: OK. 3 Alexey Melnikov : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I agree that this document is important, however there is a list of issues I would like to discuss before recommending approval of this document: 3.1 Discuss: ================== 3.1.1 DONE 1) In Section 7: ---------------------------- Quoting the draft: snmpTlstmParamsClientFingerprint OBJECT-TYPE SYNTAX Fingerprint MAX-ACCESS read-create STATUS current DESCRIPTION "A cryptographic hash of a X.509 certificate. This object should store the hash of a locally held X.509 certificate that should be used (along with the corresponding private key) when initiating a (D)TLS connection as a (D)TLS client." ::= { snmpTlstmParamsEntry 1 } How is the private key stored? + WH: That's implementation dependent as it should be, IMHO. I'd expect different implementations to store private keys in different ways, as is already done now with X.509 certificates used in other applications. Transfer and maintenance of the certificate store is out of scope of this working group. (multiple people have indicated interest in eventually creating a MIB for generic X.509 management; it's just not within the charter of ISMS to accomplish this). + Alexey: Ok. The "(along with the corresponding private key)" text made me think that the private key is a part of the snmpTlstmParamsClientFingerprint. Please reword to make it clear that that is not the case. + WH: How does this sound? "A cryptographic hash of a X.509 certificate. This object should store the hash of the public portion of a locally held X.509 certificate that should be used (along with the corresponding private key) when initiating a (D)TLS connection as a (D)TLS client." + Juergen S: Why not simply this: xxx + WH: Because previous people were concerned that we needed to mention the private key as being in existence locally and needed. That's where the wording "along with the corresponding private key" came from. + JS: Once you implement things, I think it will become pretty obvious in which situations you need to have access to the private key. But anyway, then it might be useful to discuss the fact that there is also a private key in a separate sentence to avoid confusion that the private key is part of the MIB object. + Alexey: +1 + WH: As I mentioned the original text didn't discuss public/private keys but some people found this confusing and created the existing suggested text as a replacement. Because of their opinions were voiced during the WG discussions I'm unwilling to ignore their original complaint on the text. Thus I think that we have to discuss the fact that the fingerprint is taken only over the public key and that the private key is needed to actually perform the tasks. Those two semi-separate issues are in the text as a direct result of WG discussions (IE, the text didn't even come from me). So... How about the following: "This object should store the hash of the public portion of a locally held X.509 certificate. The public key from the certificate and the corresponding private key should be used when initiating a (D)TLS connection as a (D)TLS client." Which simplifies the text a bit, gets rid of the redundancy that Juergen pointed out and separates the fingerprint portion of the text from the usage portion of the text while still mentioning how the public/private key split works. + WH: I decided that wasn't right either. How about this: This object stores the hash of the public portion of a locally held X.509 certificate. The X.509 certificate, its public key, and the corresponding private key will be used when initiating a (D)TLS connection as a (D)TLS client. + Alexey: This is better. You can also clarify that the private key is not accessible over SNMP, if you want. + WH: I'll stick with the text as is unless you think it's important to include; there are no objects that specify private key access so it's implied by the object set. + JS: I tend to agree with Wes here. We generally do not list what a MIB does not contain. 3.1.2 DISCUSS 2) In Section 7: ------------------------------- Quoting the draft: snmpTlstmCertSANAny OBJECT-IDENTITY STATUS current DESCRIPTION "Maps any of the following fields using the corresponding mapping algorithms: Type Algorithm ------------+------------------------ rfc822Name snmpTlstmCertSANRFC822Name dNSName snmpTlstmCertSANDNSName iPAddress snmpTlstmCertSANIpAddress The first matching subjectAltName value found in the certificate of the above types MUST be used when deriving the tmSecurityName." ::= { snmpTlstmCertToTSNMIdentities 5 } Does the table prescribe the order in which various subjectAltName types are checked? + WH: No, each "mapping algorithm" can prescribe it's own method of searching in order to keep the table generic. In fact, the table doesn't (by design) talk about subjectAltNames themselves and that's left up to the mapping objects that define how to map certificate contents into SNMPv3 securityNames. + Alexey: I might be missing something. This choice allows different implementations to do different things. This doesn't seem to encourage interoperability. + WH: I'm sorry if I've inadequately explained things. Interoperability is definitely assured because all the mapping algorithms we're defining in the document have deterministic results. So, using this example taken straight from the appendix we have the following mapping set up: snmpTlstmCertToTSNID = 1 (chosen by ordering preference) snmpTlstmCertToTSNFingerprint = HASH (appropriate fingerprint) snmpTlstmCertToTSNMapType = snmpTlstmCertSANAny snmpTlstmCertToTSNData = "" (not used) snmpTlstmCertToTSNStorageType = 3 (nonVolatile) snmpTlstmCertToTSNRowStatus = 4 (createAndGo) This says that if the incoming connection contains a public key in the verification tree that matches the HASH then it should use the 'snmpTlstmCertSANAny' mapping algorithm (which is assigned a unique OID within the MIB tree so it can't be confused by another conflicting definition). So, looking up the rules for snmpTlstmCertSANAny we find: Maps any of the following fields using the corresponding mapping algorithms: Type Algorithm ------------+---------------------------- rfc822Name snmpTlstmCertSANRFC822Name dNSName snmpTlstmCertSANDNSName iPAddress snmpTlstmCertSANIpAddress The first matching subjectAltName value found in the certificate of the above types MUST be used when deriving the tmSecurityName. The last paragraph clearly indicates we take the *first* SAN of the above types in order to do the mapping with. So if the certificate in use had 300 different SANs but the first was a rfc822Name containing alexey.melnikov@isode.com then that is the value that every implementation MUST pick in order to meet the standard. There is no ambiguity about what happens if you follow all the rules for the configuration specified in the MIB. The only extensibility is that future standards or enterprises can define their own mapping algorithms, assigned to their own unique OIDs that can be used in the snmpTlstmCertToTSNMapType column. We're actually expecting at some point in the future within the IETF to define a standard for mapping (deterministically of course) the kerberos principal from an otherName field. (But since that doesn't exist now, it can't be used yet.) Make more sense? + David Harrington: I think the text you quote is not deterministic because it says the tmSecurityName is derived, but doesn't specify how the derivation is done: > The first matching subjectAltName value found in the > certificate of the above types MUST be used when > deriving the tmSecurityName. You do not specify a 1:1 identity mapping MUST be used. Something derived is usually different than the original. So if the subjectAltName was "David Harrington", I could derive a tmSecurityName of "David", "Harrington", or "David Harrington H73653" and still meet the definition you quote. And if this was used in a securityName in a MIB module, and read by a remote operator, it would not be apparent that agent A's "David" was the same principal as agent B's "Harrington". And I have to agree that if everybody gets to define their own additional algorithms for derivation, even if they are registered by OID, that doesn't lend itself to interoperability. Is "IETF Review" required for every algorithm so the algorithm is at least published publicly? + WH: Well, it does. But if you missed it then more text is needed to clarify it further. In particular: DESCRIPTION "Maps any of the following fields using the corresponding mapping algorithms: Type Algorithm Note that the mapping algorithm is specified in the second column, and each of those mapping algorithms are deterministic in nature (we worked hard to make sure that all case-sensitivity, etc, was dealt with in the sub-algorithms). If you're concerned about the above not being enforced properly then I'll add the following new text (surrounded be ***s) to ensure compliance. DESCRIPTION "Maps any of the following fields using the corresponding mapping algorithms: Type Algorithm ------------+---------------------------- rfc822Name snmpTlstmCertSANRFC822Name dNSName snmpTlstmCertSANDNSName iPAddress snmpTlstmCertSANIpAddress The first matching subjectAltName value found in the certificate of the above types MUST be used when deriving the tmSecurityName. ***The mapping algorithm specified in the 'Algorithm' column MUST be used to derive the tmSecurityName.***" Does that appropriately address your concerns with respect to the "determinsticness" of the mapping? + WH: Regarding everyone defining their own algorithms: this is nothing new to the IETF or to SNMPv3. We already allow USM users, standards bodies and developers to define their own security algorithms (i.e., auth and priv) via a specified OID usable in the usmUserTable. If you want an IETF standardized algorithm, you likely need to publish it via IETF process and get an assignment in the MIB tree from IANA. However, if you work at a device-vendor and want to create your own then it's sort of up to you to get it right. E.G. Supposedly there is an OID that was created to allow interoperable 3DES encryption between certain SNMP stacks that supported that enterprise-specific assigned encryption identifier. Knowing the people that defined how it was supposed to work, I'm sure they got it right and interoperability problems haven't resulted. However, there was nothing stopping them in the USM wording that required IETF review for them to publish said OID. Nor do I think there should be. We also allow enterprise-specific security-model identifiers to be defined, but yet we don't mandate IETF-review for them to start implementing or publishing documentation about them. How is this different? The important aspect in my mind is that if two implementations implement a mapping algorithm registered at an OID and there are no flaws in the language that define the OID then will interoperability succeed? The answer is certainly yes. If the definition or the implementation is flawed then interoperability will certainly fail, just as it would for USM auth/priv algorithms and SNMPv3 security model algorithms. + Alexey: Sorry, I've missed the text about ordering. However there is another more subtle problem with this approach. My understanding is that many TLS APIs don't necessarily allow to iterate through subjectAltName types in the order are specified in the certificate. It is more common to have APIs that return SAN of a specific type. So this choice really makes it hard for applications to implement the mapping. + WH: I'm not sure about all the stacks. If this is true I suppose making the Any algorithm optional is the only way to recover. We're implementing this using OpenSSL and it seems to return stuff in order, but I'll double check that tomorrow. If other popular TLS X.509 manipulation stacks don't allow for this we have the choice of: 1) Deleting the snmpTlstmCertSANAny entirely. (I don't favor this one at all) 2) Making the snmpTlstmCertSANAny optional. (My preference) 3) Requiring everyone to implement it :-) + Alexey: I generally feel you have too many choices for extracting identity from certificates. I think this is David's point as well. And when you add algorithms that combine multiple other choices in a certain way, you increase the number of choices. But anyway, I think I need to think more about this and we should discuss this with the rest of IESG. + WH: It should be noted that the WG had this exact discussion (in Sweden) and the WG members were of the opinion that we needed the "Any" option for ease of configuration. I'm reluctant to change the current behavior given these past discussions. The output is deterministic so there is no issue with interoperability unless the APIs can't handle it. 3.1.3 CLOSED 3) In Section 7: ------------------------------ Quoting the draft: snmpTlstmCertToTSNMapType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the mapping type for deriving a tmSecurityName from a certificate. I couldn't find where allowed values for this are defined. Can you please help me find it? + WH: In this MIB document the defined values are: snmpTlstmCertSpecified snmpTlstmCertSANRFC822Name snmpTlstmCertSANDNSName snmpTlstmCertSANIpAddress snmpTlstmCertSANAny snmpTlstmCertCommonName But AutonomousType is a SNMP-ism for allowing other MIB documents to define future mapping algorithms as well as long as they're assigned to a unique OID (like those in this document are). E.G. it's already been discussed that eventually Kerberos users may wish to have a mapping algorithm for extracting kerberos principal names from the otherName type. To make things more clear about where in the current MIB the appropriate values are I've added the following text to the object DESCRIPTION clause for the snmpTlstmCertToTSNMapType column: Suitable values for assigning to this object that are defined within the SNMP-TLS-TM-MIB can be found in the snmpTlstmCertToTSNMIdentities portion of the MIB tree." I believe this will help future readers from needing to ask the same question. + Alexey: Yes, this will help. 3.1.4 CLOSED 4) In Section 7: ------------------------------ SnmpTLSAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1a" STATUS current DESCRIPTION "Represents a IPv4 address, an IPv6 address or an US-ASCII encoded hostname and port number. An IPv4 address must be in dotted decimal format followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. An IPv6 address must be a colon separated format, surrounded by square brackets ('[', US-ASCII character 0x5B, and ']', US-ASCII character 0x5D), followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. This is missing a reference to a document defining the exact IPv6 format. + WH: so is RFC5592 which I copied that text from! I added a reference to RFC3513 to fix this (both in the MIB and in the normative references). + Alexey: This should be fine, but pointing to draft-ietf-6man-text-addr-representation-07.txt would be even better (it is in RFC Editor queue now). + WH: Ok, I've changed it to the above reference with the following note added for the rfc editor: -- RFC Editor: if I-D.ietf-6man-text-addr-representation fails to get -- published ahead of this draft, RFC3513 has been agreed to be a -- sufficient replacement instead. + Alexey: Works for me. 3.1.5 CLOSED 5). ----------------- [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. DISCUSS DISCUSS: I think this reference is Normative, as it is a recommended procedure (SHOULD level requirement) for allowing the client to tell the server which hostname it is connecting to. + WH: I agree and have moved it to the normative section. + WH: Never heard directly back, but since I took his text I'm assuming this is resolved. 3.2 Comments: ================== 3.2.1 CLOSED In Section 3.1.2, the last sentence of the last paragraph: ------------------------------------------------------------------------ Implementations should offer configuration settings for mapping algorithms to SNMPv3 security levels. s/should/SHOULD ? + WH: Another IESG member suggested the same thing and I've changed it to a SHOULD + WH: Never heard directly back, but since I took his text I'm assuming this is resolved. 3.2.2 CLOSED 3.1.3. (D)TLS Connections ---------------------------------------- As an implementation hint: note that the (D)TLS internal SessionID does not meet these requirements, since it can change over the life of the connection as seen by the TLSTM (for example, during renegotiation), and does not necessarily uniquely idenfify a TLSTM session (there can be multiple TLSTM sessions sharing the same D(TLS) internal SessionID). typo: identify + WH: thanks, fixed! + WH: Never heard directly back, but since I took his text I'm assuming this is resolved. 3.2.3 DONE In Section 5.1.1: ----------------------------- The first reference to acronym LCD should be expanded and should point to where it is defined. + WH: I've changed the source text of the initial acronym use to read: The TLS Transport Model queries the Local Configuration Datastore (LCD) (see Section 3.4.2) using the transport parameters (source and destination IP addresses and ports) to determine if a session already exists. 3.2.4 DONE In Section 7: ------------------------- Quoting the draft: snmpTlstmCertToTSNRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row. This object may be used to create or remove rows from this table. To create a row in this table, an administrator must set this object to either createAndGo(4) or createAndWait(5). Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the snmpTlstmParamsRowStatus column is 'notReady'. Is 'notReady' correspond to an actual value of this field? (Similar question regarding 'notReady' value in snmpTlstmParamsRowStatus and snmpTlstmAddrRowStatus.) + WH: It's a standard value for the RowStatus type, so yes it corresponds to an actual value. I've gone ahead and modified the text so it reads notReady(3) in all three places to make it match the rest of the text style when referring to enum values. Thanks for the suggestion. 3.2.5 CLOSED Also in Section 7: -------------------------------- Quoting the draft: snmpTlstmServerInvalidCertificate NOTIFICATION-TYPE OBJECTS { snmpTlstmAddrServerFingerprint, snmpTlstmSessionInvalidServerCertificates} STATUS current DESCRIPTION "Notification that the server certificate presented by an SNMP over (D)TLS server could not be validated even if the fingerprint or expected validation path was known. I.E., a cryptographic validation occurred during certificate validation processing. Is the word "error" missing after the word "validation"? + WH: Yes it is; thanks for catching it. + WH: Never heard directly back, but since I took his text I'm assuming this is resolved. 3.2.6 CLOSED 8.1. Sessions ---------------------------- Quoting the draft: Whenever possible, implementations SHOULD provide graceful session termination through the use of disconnect messages. Did you mean TLS disconnect messages here? + WH: Yep; I added "TLS" per your recommendation + WH: Never heard directly back, but since I took his text I'm assuming this is resolved. 4 Peter Saint-Andre ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4.1 Discuss: ==================== 4.1.1 CLOSED The definition of snmpTlstmCertSANIpAddress mentions that ----------------------------------------------------------------------- securityName lengths might exceed what VACM can handle; doesn't this introduce possible interoperability problems? + WH: The end result would need to be the same, based on the definition of the VACM processing rules: the message would be discarded. The 32-octet limitation of the VACM is not something we can fix within the scope of the ISMS working group (though many people would like this problem to go away). So in the end, no that no interoperability problem exists as all implementations MUST do the same thing: discard the packet (since no access rule would exist allowing it through). That doesn't mean we're left in a wonderful position and the best we can do is warn the operators; hence the warning in the MIB. + Peter: OK, I see your point: it's not an interoperability problem, but those who deploy the technology need to be aware of the limitation and plan accordingly. 4.1.2 CLOSED The definition of SnmpTLSAddress states that ---------------------------------------------------------- "internationalized hostnames are encoded in US-ASCII as specified in RFC 3490", but I think this could be defined more precisely because (1) RFC 3490 does not talk about "internationalized hostnames", (2) you need to state that you are using the ToASCII operation, and (3) you need to specify whether the UseSTD3ASCIIRules flag is set. This definition also appears to make normative references to RFC 1033 and RFC 3490, but those specifications are not included in the Normative References section. Finally, this definition references RFC 3986 but that specification is never used here. + WH: I've changed the text to the following to address your concerns; please let me know if you believe it needs further changes. A hostname is always in US-ASCII (as per RFC1033); internationalized hostnames are encoded in US-ASCII as domain names after transformation via the ToASCII operation specified in RFC 3490. The ToASCII operation MUST be performed with the UseSTD3ASCIIRules flag set. The hostname is followed by a colon ':' (US-ASCII character 0x3A) and a decimal port number in US-ASCII. The name SHOULD be fully qualified whenever possible. + WH: references for 3490 and 1033 moved to the normative section. + WH: The 3986 reference has been removed (in the process of responding to other similar comments). + Peter: Excellent. 4.2 Comments: ================== 4.2.1 CLOSED Section 1.1 has: ------------------------------ Quoting the draft: "Authentication" in this document typically refers to the English meaning of "serving to prove the authenticity of" the message, not data source authentication or peer identity authentication. Why not reference the definition from RFC 4949? + David H: Let me wade in as co-chair of the SNMPv3 WG, concluded. [quoted above] because then the definition used in this document would not be consistent with definitions used in the SNMPv3 standard (RFC3411-3418) or the SNMP Transport subsystem extension (RFC5590), the Transport Security Model (RFC5591) the SSHTM (RFC5592), multiple (now mostly Historic) versions of SNMPv2, the SNMP Coexistence BCP, and a range of other SNMP documents, including every MIB module that has the required MIB Security boilerplate. For example, the term privacy has existed in SNMP at least since RFC1352 (July 1992). It doesn't mean the rights of an individual to decide how their information can be shared; it means protecting the confidentiality of information in SNMP messages. When SNMPv3 was advanced from proposed standard (1998) to draft (1999) to full standard (2002), the IESG accepted that it was better to have consistency within the long list of SNMP security documents than to rewrite everything to match the (contentious) glossary document that was still in the process of being written in 2000. my $.02 ;-) dbh + WH: I agree with David; if we were to rewrite the whole SNMP system we'd likely use consistent terminology. But as this new document is a small piece of a much larger system it helps if all the terminology is consistent first within the system itself. + Peter: OK, mostly I was just checking because it seems good for us all to use consistent terminology, where possible. 4.2.2 CLOSED I realize that RFC 3411 talks about "privacy", but the -------------------------------------------------------------------- more modern term is "data confidentiality" (see, again, RFC 4949). + WH: duplicate response as the above as it's really the same issue. + Peter: See above. 4.2.3 CLOSED Forgive my ignorance regarding SNMP/SMI, but I can't seem ----------------------------------------------------------------------- to find a definition of "transport domain"; is it a DNS domain name, a trust domain, or something else? (It seems to be more like an address type.) It might help to make this clearer in the definitions of the snmpTLSTCPDomain and snmpDTLSUDPDomain transport domains. + WH: Well, this document is really an standards implementation of what is defined in RFC5590. It's important to understand that document before reading this one, as it says in the first sentence of the introduction. In fact, RFC5590 is titled "Transport Subsystem for the Simple Network Management Protocol". That being said, transport domains are very much an SNMP-ism and it would certainly be hard to understand if this was the first SNMP document you had read. I'll put in a reference to RFC2579 in the object references section which I think is the best that can really be done. + Peter: Thanks for the clarification. 4.2.4 DONE The definition of snmpTlstmCertSANDNSName mentions -------------------------------------------------------------- converting the DNS domain name to lower case. Is the handling of internationalized domain names inherited from dNSName in RFC 5280 (i.e., convert to the ACE encoding)? + WH: RFC5280 specifically mentions that DNS names are compared in a case-insensitive manner. And therefore since the value 'Foo.example.com' must be equal within the resulting derived tmSecurityName the working group decided to make all DNS name instances lower case so that no matter what was in the certificate we'd use names that would also be comparatively the same. + Peter: OK, thanks for the clarification. It might be good to add a short note to the effect that this requires one step beyond the comparison rules specified in Section 7.2 of RFC 5280. + WH: Well, we're not actually doing a comparison at this particular point. We're taking data out of the certificate to make use of. The reason for requiring the lower-casing is to make sure that because certificates *can* be constructed with two values that are supposed to be the same from the certificate's point of view and that our resulting derived label (tmSecurityName) will also be unique per value from the certificate. But we're not doing a comparison, we're deriving a value from a X.509 field. + Peter: Change "comparison" to "canonicalization" or whatever term you prefer and I think my comment still makes sense as an implementation note -- you could take the output of a string preparation library that supports the Nameprep profile or a security library that supports RFC 5280 but you would then need to perform an additional step of lowercasing the domain name before you could correctly do something useful with the output. I'm talking about something like the following parenthetical remark: snmpTlstmCertSANDNSName OBJECT-IDENTITY STATUS current DESCRIPTION "Maps a subjectAltName's dNSName to a tmSecurityName after first converting it to all lower case (note that [RFC5280] does not specify converting to lower case so this involves an extra step)." + WH: Ok, I'll add that to the MIB objects minus the []s around the RFC5280 since hard references aren't allowed in MIBs. Thanks for suggesting the text you wished to see in place. 4.2.5 CLOSED Is there any provision for supporting subjectAltName ------------------------------------------------------------------ extension types other than dNSName, rfc822name, and iPAddress, such as SRVName (RFC 4395) or uniformResourceIdentifier (cf. RFC 4088)? + WH: Not at the moment. Others were discussed as "future desires" but the system as-is can be extended in the future with future mapping algorithms. So this document only defines a few of the possibilities, there is nothing preventing a future (potentially short) document from defining new ones. + Peter: OK 4.2.6 CLOSED Is there a preferred order of matching subjectAltName ------------------------------------------------------------------- extensions? + WH: The objects specifically call out that you MUST pick the first one in the list that is a match. + Peter: I must have missed that. My apologies. 4.2.7 DISCUSS How exactly does an entity prepare for matching of ----------------------------------------------------------------- subjectAltName extensions? See the discussion in draft-saintandre-tls-server-id-check for related material. + WH: I'm not entirely sure I'm exactly matching what you're asking about. Certificate SAN to tmSecurityName mapping was what you were last asking about, but I suspect you've now switched to checking for name validity when making connections? The working group recognized that there was new work being undertaken in this area. The current text in the tlstmAddrTable object was added in an effort to put in wording that addressed the issue of connection setup. If you have suggested changes or additions that you feel are important I'd gladly consider them. + Peter: By "prepare for" I mean that connecting party must have some inputs to the matching operation so that it has a canonical reference identifier that it expects the other party to present in a certificate. For example, if I type "[https://www.example.com/]" into the URL line of my browser then my browser might expect the presented certificate to include one of the following identifiers: uniformResourceIdentifier = [https://www.example.com/] dNSName = www.example.com dNSName = *.example.com CN = www.example.com etc. We have a discussion about this in draft-saintandre-tls-server-id-check for various application protocols, which might provide some concepts that you could re-use. + WH: This is the text from the document that describes setting up connections and what to expect from the certificate contents. Is this text insufficient in your mind then? If the server's presented certificate has passed certification path validation [RFC5280] to a configured trust anchor, and an active row exists with a zero-length snmpTlstmAddrServerFingerprint value, then the snmpTlstmAddrServerIdentity column contains the expected host name. This expected host name is then compared against the server's certificate as follows: - Implementations MUST support matching the expected host name against a dNSName in the subjectAltName extension field and MAY support checking the name against the CommonName portion of the subject distinguished name. - The '*' (ASCII 0x2a) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), but only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them. - If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format for performing comparisons, as specified in Section 7 of [RFC5280]. If the expected host name fails these conditions then the connection MUST be closed. 4.2.8 DONE It might be appropriate for this specification to say ----------------------------------------------------------------- that checking of the Common Name is a fallback and that checking of subjectAltName extensions is preferred. + WH: The snmpTlstmCertToTSNTable table description says this already. I'd be happy to mention it in other places too if you feel it was appropriate and had places that you think such a NOT RECOMMENDED statement belongs. + Peter: The specification contains the following text regarding the Common Name: ### 7. MIB Module Definition snmpTlstmCertCommonName OBJECT-IDENTITY STATUS current DESCRIPTION "Maps a certificate's CommonName to a tmSecurityName after converting it to a UTF-8 encoding." [...No mention that this usage is NOT RECOMMENDED or that objects of type snmpTlstmCertSAN* are preferred...] snmpTlstmCertToTSNTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpTlstmCertToTSNEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION Users are encouraged to make use of certificates with subjectAltName fields that can be used as tmSecurityNames so that a single root CA certificate can allow all child certificate's subjectAltName to map directly to a tmSecurityName via a 1:1 transformation. However, this table is flexible to allow for situations where existing deployed certificate infrastructures do not provide adequate subjectAltName values for use as tmSecurityNames. Certificates may also be mapped to tmSecurityNames using the CommonName portion of the Subject field. However, the usage of the CommonName field is deprecated and thus this usage is NOT RECOMMENDED. Direct mapping from each individual certificate fingerprint to a tmSecurityName is also possible but requires one entry in the table per tmSecurityName and requires more management operations to completely configure a device." snmpTlstmAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpTlstmAddrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION - Implementations MUST support matching the expected host name against a dNSName in the subjectAltName extension field and SHOULD support checking the name against the common name portion of the subject distinguished name. [...Here Common Name appears to be a SHOULD...] A.2. Configuring the Command Responder The above is an example of how to map a particular certificate to a particular tmSecurityName. It is recommended, however, that users make use of direct subjectAltName or CommonName mappings where possible as it provides a more scalable approach to certificate management. [...Here Common Name appears to be RECOMMENDED...] ### Thus it appears that there are some inconsistencies in the text regarding whether Common Name is NOT RECOMMENDED or RECOMMENDED. Peter + WH: Ok, I'll make the following changes to strengthen the text. The last text you discussed was in the appedix and was complete rewritten lately by David H. and myself and no longer contains that recommendation at all. + Changed text 1 (addition of second sentence) DESCRIPTION "Maps a certificate's CommonName to a tmSecurityName after converting it to a UTF-8 encoding. The usage of CommonNames is deprecated and users are encouraged to use subjectAltName mapping methods instead." + Changed text 2 (SHOULD -> MAY): - Implementations MUST support matching the expected host name against a dNSName in the subjectAltName extension field and MAY support checking the name against the common name portion of the subject distinguished name. Look good? 5 Tim Polk ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 5.1 DONE RFC 5590 states: ========================== It is considered desirable by some industry segments that SNMP Transport Models utilize transport-layer security that addresses perfect forward secrecy at least for encryption keys. Perfect forward secrecy guarantees that compromise of long-term secret keys does not result in disclosure of past session keys. Each proposed Transport Model should include a discussion in its security considerations of whether perfect forward secrecy is appropriate for that Transport Model. This document does not appear to include any such discussion. + WH: Would the addition of the following text to the security considerations section satisfy this in your eyes: The use of Perfect Forward Secrecy is RECOMMENDED and can be provided by TLS with appropriately selected cipher suites, as discussed in appendix F of [RFC5246]. 5.2 CLOSED The document requires use of TLS, and mandates ========================================================== certificate-based authentication for both the client and server. This provides a nice baseline with a reasonably consistent level of security. However, many people consider SSL and TLS to be interchangeable, and early versions of SSL do not provide an acceptable level of security. I would like to see text along the following lines added to this specification: Implementations of TLS typically support multiple versions of the Transport Layer Security protocol as well as the older Secure Sockets Layer (SSL) protocol. Because of known security vulnerabilities, TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0. See Appendix E.2 of [TLS] for further details. The Security Considerations would be one possible location for this text, but the exact placement is not an issue... + WH: I've added that exact text to a new security considerations sub-section entitled "TLS Version Requirements". + WH: Never heard directly back, but since I took his text I'm assuming this is resolved. -- Wes Hardaker Cobham Analytic Solutions From ietfdbh@comcast.net Wed May 5 16:08:14 2010 Return-Path: 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 EEC963A6AE9 for ; Wed, 5 May 2010 16:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_50=0.001] 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 FFXa0N1i5Smo for ; Wed, 5 May 2010 16:08:13 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by core3.amsl.com (Postfix) with ESMTP id 188393A68D4 for ; Wed, 5 May 2010 16:07:58 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta14.westchester.pa.mail.comcast.net with comcast id Dmix1e0021c6gX85Ez7ldS; Wed, 05 May 2010 23:07:45 +0000 Received: from Harrington73653 ([67.189.235.106]) by omta23.westchester.pa.mail.comcast.net with comcast id Dz7l1e0042JQnJT3jz7lWU; Wed, 05 May 2010 23:07:45 +0000 From: "David Harrington" To: "'Wes Hardaker'" , References: Date: Wed, 5 May 2010 19:07:41 -0400 Message-ID: <097301caeca7$c385a650$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acrskm/ibENq1r8mQTadYg+AVXwmMwACgCNQ Cc: iesg@ietf.org Subject: Re: [Isms] Status of IESG-review changes for draft-ietf-isms-dtls-tm 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: , X-List-Received-Date: Wed, 05 May 2010 23:08:14 -0000 Hi, > This is a very important and well written document, and before > baloting a YES vote I would like to clarify a few issues: > I agree this is a well-written document, except those portions copied from my document ;-) > > 3.1.2 DISCUSS 2) In Section 7: > ------------------------------- > > Quoting the draft: > > snmpTlstmCertSANAny OBJECT-IDENTITY > STATUS current > DESCRIPTION "Maps any of the following fields > using the > corresponding mapping algorithms: > > Type Algorithm > ------------+------------------------ > rfc822Name > snmpTlstmCertSANRFC822Name > dNSName > snmpTlstmCertSANDNSName > iPAddress > snmpTlstmCertSANIpAddress > > The first matching subjectAltName value > found in the certificate of the > above types > MUST be used when deriving the > tmSecurityName." > ::= { snmpTlstmCertToTSNMIdentities 5 } > > Does the table prescribe the order in which various > subjectAltName types are checked? > > + WH: No, each "mapping algorithm" can prescribe it's own > method of searching in order to keep the table generic. > In fact, the table doesn't (by design) talk about > subjectAltNames themselves and that's left up to the mapping > objects that define how to map certificate contents into > SNMPv3 securityNames. > > + Alexey: I might be missing something. This choice allows > different implementations to do different things. This > doesn't seem to encourage interoperability. > > + WH: I'm sorry if I've inadequately explained things. > Interoperability is definitely assured because all the > mapping algorithms we're defining in the document have > deterministic results. > > So, using this example taken straight from the appendix we > have the following mapping set up: > > snmpTlstmCertToTSNID = 1 > (chosen by > ordering preference) > snmpTlstmCertToTSNFingerprint = HASH > (appropriate fingerprint) > snmpTlstmCertToTSNMapType = snmpTlstmCertSANAny > snmpTlstmCertToTSNData = "" (not used) > snmpTlstmCertToTSNStorageType = 3 (nonVolatile) > snmpTlstmCertToTSNRowStatus = 4 (createAndGo) > > This says that if the incoming connection contains a public > key in the verification tree that matches the HASH then it > should use the 'snmpTlstmCertSANAny' mapping algorithm > (which is assigned a unique OID within the MIB tree so it > can't be confused by another conflicting definition). > > So, looking up the rules for snmpTlstmCertSANAny we find: > > Maps any of the following fields using the > corresponding mapping algorithms: > > Type Algorithm > ------------+---------------------------- > rfc822Name snmpTlstmCertSANRFC822Name > dNSName snmpTlstmCertSANDNSName > iPAddress snmpTlstmCertSANIpAddress > > The first matching subjectAltName value found in the > certificate of the above types MUST be used when > deriving the tmSecurityName. > > The last paragraph clearly indicates we take the *first* SAN > of the above types in order to do the mapping with. So if > the certificate in use had 300 different SANs but the first > was a rfc822Name containing alexey.melnikov@isode.com then > that is the value that every implementation MUST pick in > order to meet the standard. There is no ambiguity about > what happens if you follow all the rules for the > configuration specified in the MIB. > > The only extensibility is that future standards or > enterprises can define their own mapping algorithms, > assigned to their own unique OIDs that can be used in the > snmpTlstmCertToTSNMapType column. We're actually expecting > at some point in the future within the IETF to define a > standard for mapping (deterministically of course) the > kerberos principal from an otherName field. (But since that > doesn't exist now, it can't be used yet.) > > Make more sense? > > + David Harrington: > > I think the text you quote is not deterministic because it > says the tmSecurityName is derived, but doesn't specify how > the derivation is done: > > > The first matching subjectAltName value found in the > > certificate of the above types MUST be used when > > deriving the tmSecurityName. > > You do not specify a 1:1 identity mapping MUST be > used. Something derived is usually different than the > original. So if the subjectAltName was "David Harrington", I > could derive a tmSecurityName of "David", "Harrington", or > "David Harrington H73653" and still meet the definition you > quote. And if this was used in a securityName in a MIB > module, and read by a remote operator, it would not be > apparent that agent A's "David" was the same principal as > agent B's "Harrington". > > And I have to agree that if everybody gets to define their > own additional algorithms for derivation, even if they are > registered by OID, that doesn't lend itself to > interoperability. Is "IETF Review" required for every > algorithm so the algorithm is at least published publicly? > > + WH: Well, it does. But if you missed it then more text is > needed to clarify it further. > > In particular: > > DESCRIPTION "Maps any of the following fields using the > corresponding mapping algorithms: > > Type Algorithm > > > Note that the mapping algorithm is specified in the second > column, and each of those mapping algorithms are > deterministic in nature (we worked hard to make sure that > all case-sensitivity, etc, was dealt with in the > sub-algorithms). > > If you're concerned about the above not being enforced > properly then I'll add the following new text (surrounded be > ***s) to ensure compliance. > > DESCRIPTION "Maps any of the following fields using the > corresponding mapping algorithms: > > Type Algorithm > > ------------+---------------------------- > rfc822Name > snmpTlstmCertSANRFC822Name > dNSName > snmpTlstmCertSANDNSName > iPAddress > snmpTlstmCertSANIpAddress > > The first matching subjectAltName > value found in the > certificate of the above types > MUST be used when > deriving the tmSecurityName. > ***The mapping algorithm > specified in the 'Algorithm' > column MUST be used to > derive the tmSecurityName.***" > > Does that appropriately address your concerns with respect > to the "determinsticness" of the mapping? > > + WH: Regarding everyone defining their own algorithms: this > is nothing new to the IETF or to SNMPv3. We already allow > USM users, standards bodies and developers to define their > own security algorithms (i.e., auth and priv) via a > specified OID usable in the usmUserTable. If you want an > IETF standardized algorithm, you likely need to publish it > via IETF process and get an assignment in the MIB tree > from IANA. However, if you work at a device-vendor and > want to create your own then it's sort of up to you to get > it right. E.G. Supposedly there is an OID that was > created to allow interoperable 3DES encryption between > certain SNMP stacks that supported that > enterprise-specific assigned encryption > identifier. Knowing the people that defined how it was > supposed to work, I'm sure they got it right and > interoperability problems haven't resulted. However, there > was nothing stopping them in the USM wording that required > IETF review for them to publish said OID. Nor do I think > there should be. We also allow enterprise-specific > security-model identifiers to be defined, but yet we don't > mandate IETF-review for them to start implementing or > publishing documentation about them. How is this > different? > > The important aspect in my mind is that if two > implementations implement a mapping algorithm registered > at an OID and there are no flaws in the language that > define the OID then will interoperability succeed? The > answer is certainly yes. If the definition or the > implementation is flawed then interoperability will > certainly fail, just as it would for USM auth/priv > algorithms and SNMPv3 security model algorithms. > > + Alexey: > > Sorry, I've missed the text about ordering. > > However there is another more subtle problem with this > approach. My understanding is that many TLS APIs don't > necessarily allow to iterate through subjectAltName types in > the order are specified in the certificate. It is more > common to have APIs that return SAN of a specific type. So > this choice really makes it hard for applications to > implement the mapping. > > + WH: > > I'm not sure about all the stacks. If this is true I > suppose making the Any algorithm optional is the only way to > recover. We're implementing this using OpenSSL and it seems > to return stuff in order, but I'll double check that > tomorrow. > > If other popular TLS X.509 manipulation stacks don't allow > for this we have the choice of: > > 1) Deleting the snmpTlstmCertSANAny entirely. > (I don't favor this one at all) > > 2) Making the snmpTlstmCertSANAny optional. > (My preference) > > 3) Requiring everyone to implement it :-) > > + Alexey: > > I generally feel you have too many choices for > extracting identity > from certificates. I think this is David's point as well. > And when you add algorithms that combine multiple > other choices in a > certain way, you increase the number of choices. > > But anyway, I think I need to think more about this > and we should > discuss this with the rest of IESG. > > + WH: > > It should be noted that the WG had this exact discussion (in > Sweden) and the WG members were of the opinion that we > needed the "Any" option for ease of configuration. I'm > reluctant to change the current behavior given these past > discussions. > > The output is deterministic so there is no issue with > interoperability unless the APIs can't handle it. > I still have concerns about interoperability. I think we'll talk about this during the telechat tomorrow. > 3.2.1 CLOSED In Section 3.1.2, the last sentence of the last > paragraph: > -------------------------------------------------------------- > ---------- > > Implementations SHOULD offer configuration settings for > mapping algorithms to SNMPv3 security levels. > If we say it SHOULD, then shouldn't we provide the appropriate tables in the MIB module? I am not certain what such a mapping would look like. > > 4.2.3 CLOSED Forgive my ignorance regarding SNMP/SMI, but I > can't seem > -------------------------------------------------------------- > --------- > to find a definition of "transport domain"; is it a DNS domain > name, a trust domain, or something else? (It seems to be more > like an address type.) It might help to make this clearer in > the definitions of the snmpTLSTCPDomain and snmpDTLSUDPDomain > transport domains. > > document you had read. I'll put in a reference to RFC2579 Actually, 3417 is probably the preferred reference. dbh From wjhns1@hardakers.net Wed May 5 16:21:45 2010 Return-Path: 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 B70C728C1A8; Wed, 5 May 2010 16:21:45 -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 Hs9nqdS0zyCO; Wed, 5 May 2010 16:21:43 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 0C4463A677E; Wed, 5 May 2010 16:20:52 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id A487A98134; Wed, 5 May 2010 16:20:39 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <097301caeca7$c385a650$0600a8c0@china.huawei.com> Date: Wed, 05 May 2010 16:20:39 -0700 In-Reply-To: <097301caeca7$c385a650$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 5 May 2010 19:07:41 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: iesg@ietf.org, isms@ietf.org Subject: Re: [Isms] Status of IESG-review changes for draft-ietf-isms-dtls-tm 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: , X-List-Received-Date: Wed, 05 May 2010 23:21:46 -0000 > The output is deterministic so there is no issue with > interoperability unless the APIs can't handle it. > DH> I still have concerns about interoperability. I think we'll talk DH> about this during the telechat tomorrow. I'd love to see a case that points out where something isn't deterministic given the existing specifications. Please provide! > 3.2.1 CLOSED In Section 3.1.2, the last sentence of the last > paragraph: > -------------------------------------------------------------- > ---------- > > Implementations SHOULD offer configuration settings for > mapping algorithms to SNMPv3 security levels. > DH> If we say it SHOULD, then shouldn't we provide the appropriate DH> tables in the MIB module? I am not certain what such a mapping DH> would look like. We even agreed in the WG at one point that such infrastructure tables would be nice to have but would need to be defined in PKIX, not in ISMS. > 4.2.3 CLOSED Forgive my ignorance regarding SNMP/SMI, but I > can't seem > -------------------------------------------------------------- > --------- > to find a definition of "transport domain"; is it a DNS domain > name, a trust domain, or something else? (It seems to be more > like an address type.) It might help to make this clearer in > the definitions of the snmpTLSTCPDomain and snmpDTLSUDPDomain > transport domains. > > document you had read. I'll put in a reference to RFC2579 DH> Actually, 3417 is probably the preferred reference. 3417 defines the current transport mechanisms (e.g. UDP). RFC2579, on the other-hand, defines the TDomain and TAddress TC which is the base for them all. -- Wes Hardaker Cobham Analytic Solutions From ietfdbh@comcast.net Wed May 5 16:48:10 2010 Return-Path: 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 420103A690D for ; Wed, 5 May 2010 16:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.746 X-Spam-Level: X-Spam-Status: No, score=-0.746 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_05=-1.11] 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 a1xv3aUajEmm for ; Wed, 5 May 2010 16:48:10 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 7496F3A6967 for ; Wed, 5 May 2010 16:48:08 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Do4F1e00s1vXlb85BznwQL; Wed, 05 May 2010 23:47:56 +0000 Received: from Harrington73653 ([67.189.235.106]) by omta17.westchester.pa.mail.comcast.net with comcast id Dznw1e0012JQnJT3dznwmo; Wed, 05 May 2010 23:47:56 +0000 From: "David Harrington" To: "'Wes Hardaker'" References: <097301caeca7$c385a650$0600a8c0@china.huawei.com> Date: Wed, 5 May 2010 19:47:54 -0400 Message-ID: <097801caecad$61936f30$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcrsqZP9ZIX5JWA2SliCcG8/frYwewAAnfXg Cc: isms@ietf.org, iesg@ietf.org Subject: Re: [Isms] Status of IESG-review changes for draft-ietf-isms-dtls-tm 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: , X-List-Received-Date: Wed, 05 May 2010 23:48:10 -0000 > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Wednesday, May 05, 2010 7:21 PM > To: David Harrington > Cc: 'Wes Hardaker'; isms@ietf.org; iesg@ietf.org > Subject: Re: Status of IESG-review changes for draft-ietf-isms-dtls-tm > > > The output is deterministic so there is no issue with > > interoperability unless the APIs can't handle it. > > > > DH> I still have concerns about interoperability. I think we'll talk > DH> about this during the telechat tomorrow. > > I'd love to see a case that points out where something isn't > deterministic given the existing specifications. Please provide! My concerns are not about deterministic; they are about interoperability. > > > 3.2.1 CLOSED In Section 3.1.2, the last sentence of the last > > paragraph: > > -------------------------------------------------------------- > > ---------- > > > > Implementations SHOULD offer configuration settings for > > mapping algorithms to SNMPv3 security levels. > > > > DH> If we say it SHOULD, then shouldn't we provide the appropriate > DH> tables in the MIB module? I am not certain what such a mapping > DH> would look like. > > We even agreed in the WG at one point that such infrastructure tables > would be nice to have but would need to be defined in PKIX, > not in ISMS. PKIX would not be the right place to define how to ***map them to SNMPv3*** security levels. Or do I not understand what mappings you think should be provided? Maybe I am confused because this spec talks a lot about "mapping algorithms"; maybe you are thinking of something else here than I am. As I said, I am not certain what such a mapping would look like. Can you tell us what you think it would look like? > > > 4.2.3 CLOSED Forgive my ignorance regarding SNMP/SMI, but I > > can't seem > > -------------------------------------------------------------- > > --------- > > to find a definition of "transport domain"; is it a > DNS domain > > name, a trust domain, or something else? (It seems > to be more > > like an address type.) It might help to make this clearer in > > the definitions of the snmpTLSTCPDomain and > snmpDTLSUDPDomain > > transport domains. > > > > document you had read. I'll put in a reference to RFC2579 > > DH> Actually, 3417 is probably the preferred reference. > > 3417 defines the current transport mechanisms (e.g. UDP). RFC2579, on > the other-hand, defines the TDomain and TAddress TC which is the base > for them all. OK. > -- > Wes Hardaker > Cobham Analytic Solutions > From wjhns1@hardakers.net Wed May 5 21:49:17 2010 Return-Path: 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 C124B28C0D9; Wed, 5 May 2010 21:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 cfrzoctiT96z; Wed, 5 May 2010 21:49:16 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 579CA28C0D6; Wed, 5 May 2010 21:49:16 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 931D79827E; Wed, 5 May 2010 21:49:02 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <097301caeca7$c385a650$0600a8c0@china.huawei.com> <097801caecad$61936f30$0600a8c0@china.huawei.com> Date: Wed, 05 May 2010 21:49:02 -0700 In-Reply-To: <097801caecad$61936f30$0600a8c0@china.huawei.com> (David Harrington's message of "Wed, 5 May 2010 19:47:54 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: iesg@ietf.org, isms@ietf.org Subject: Re: [Isms] Status of IESG-review changes for draft-ietf-isms-dtls-tm 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: , X-List-Received-Date: Thu, 06 May 2010 04:49:17 -0000 >>>>> On Wed, 5 May 2010 19:47:54 -0400, "David Harrington" said: >> I'd love to see a case that points out where something isn't >> deterministic given the existing specifications. Please provide! DH> My concerns are not about deterministic; they are about DH> interoperability. Ah; then I'd love to have the concerns explained! More specifically, I haven't heard a description of an actual problem (and I love to fix problems, but I can't do so without the described complaint ;-). The only issue I have in my head is that an operator MAY create a situation where multiple certificates all map to a given tmSecurityName. This is possible a feature in their eyes, but it could be done by mistake. But certificates already contain this problem as if you have two CAs as trust anchors there is nothing that says the CommonName or any other value in a certificate can't conflict between the two CAs. IE, the problem isn't unique to SNMP. What operators should do is avoid those situations and ensure they understand and trust their CA's publication policies. DH> PKIX would not be the right place to define how to ***map them to DH> SNMPv3*** security levels. I think I misread a sentence early on and I apologize for that because I missed the original point. Defining a mapping table to security levels is technically possible and would probably look something close to: |------------------------------+-------------------------------| | TLS Suite (index(es)) | securityLevel (output column) | |------------------------------+-------------------------------| | TLS_RSA_WITH_AES_128_CBC_SHA | authPriv | | TLS_NULL_WITH_NULL_NULL | noAuthNoPriv | | TLS_RSA_WITH_NULL_SHA256 | authNoPriv | | ... | ... | |------------------------------+-------------------------------| I don't think it would be a complex table. But we decided not to go there and simply declare than "NULL" must not be used to fulfill an "auth" or "priv" flag (which the document already says). -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Wed May 5 23:34:15 2010 Return-Path: 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 B607C3A6ACE; Wed, 5 May 2010 23:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_40=-0.185, 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 7BgZ69B-WBoq; Wed, 5 May 2010 23:34:14 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A12C63A6A6B; Wed, 5 May 2010 23:34:14 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B470C0024; Thu, 6 May 2010 08:34:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GONtMPtIre76; Thu, 6 May 2010 08:34:00 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F439C000C; Thu, 6 May 2010 08:33:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3225D11F1D83; Thu, 6 May 2010 08:33:57 +0200 (CEST) Date: Thu, 6 May 2010 08:33:57 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100506063357.GA55813@elstar.local> Mail-Followup-To: Wes Hardaker , David Harrington , "iesg@ietf.org" , "isms@ietf.org" References: <097301caeca7$c385a650$0600a8c0@china.huawei.com> <097801caecad$61936f30$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "iesg@ietf.org" , "isms@ietf.org" Subject: Re: [Isms] Status of IESG-review changes for draft-ietf-isms-dtls-tm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 06:34:15 -0000 On Thu, May 06, 2010 at 06:49:02AM +0200, Wes Hardaker wrote: > DH> PKIX would not be the right place to define how to ***map them to > DH> SNMPv3*** security levels. > > I think I misread a sentence early on and I apologize for that because I > missed the original point. > > Defining a mapping table to security levels is technically possible and > would probably look something close to: > > |------------------------------+-------------------------------| > | TLS Suite (index(es)) | securityLevel (output column) | > |------------------------------+-------------------------------| > | TLS_RSA_WITH_AES_128_CBC_SHA | authPriv | > | TLS_NULL_WITH_NULL_NULL | noAuthNoPriv | > | TLS_RSA_WITH_NULL_SHA256 | authNoPriv | > | ... | ... | > |------------------------------+-------------------------------| > > I don't think it would be a complex table. But we decided not to go > there and simply declare than "NULL" must not be used to fulfill an > "auth" or "priv" flag (which the document already says). And this approach seems to be consistent with what RFC 5592 does. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From root@core3.amsl.com Thu May 6 12:45:02 2010 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6621428C121; Thu, 6 May 2010 12:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100506194502.6621428C121@core3.amsl.com> Date: Thu, 6 May 2010 12:45:02 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-dtls-tm-12.txt 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: , X-List-Received-Date: Thu, 06 May 2010 19:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) Author(s) : W. Hardaker Filename : draft-ietf-isms-dtls-tm-12.txt Pages : 64 Date : 2010-05-06 This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This transport model is designed to meet the security and operational needs of network administrators. It supports sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g. UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the TLS Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-dtls-tm-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-06123942.I-D@ietf.org> --NextPart-- From mundy@tislabs.com Thu May 6 14:59:49 2010 Return-Path: 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 908EC3A6A98 for ; Thu, 6 May 2010 14:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 VQScCNH96KyD for ; Thu, 6 May 2010 14:59:48 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 966883A6A6F for ; Thu, 6 May 2010 14:59:48 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o46LxZoh029364 for ; Thu, 6 May 2010 16:59:35 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o46LxXpa010135; Thu, 6 May 2010 16:59:34 -0500 Received: from hobbes.columbia.sparta.com ([157.185.80.174]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 May 2010 17:59:33 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by hobbes.columbia.sparta.com (Postfix) with ESMTP id 62803227DAE5; Thu, 6 May 2010 17:59:32 -0400 (EDT) Date: Thu, 6 May 2010 17:59:32 -0400 From: mundy@tislabs.com To: isms@ietf.org Message-ID: <20100506175932267697.1f5848bb@tislabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.9 X-OriginalArrivalTime: 06 May 2010 21:59:33.0458 (UTC) FILETIME=[691FB320:01CAED67] Cc: mundy@sparta.com Subject: [Isms] Proposal for progression of VACM/RADIUS ID 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: , X-List-Received-Date: Thu, 06 May 2010 21:59:49 -0000 Trying to come up with a way to move the VACM/RADIUS draft forward, we obviously had a difficult time determining what and how many counters and notifications should be included in the specification. As Juergen pointed out, I've not been an active participant in the technical discussions and don't have any particular positions to support or oppose - my objective here is to identify how we should proceed forward with the VACM/RADIUS document. My approach to this has been to carefully read all of the related mail on the list (actually a couple of readings) so I could come up a reasoned way for us to move forward. Based on these readings, a few things of note related to counters/notifications stuck out to me: - No one made any strong arguments that any of these were important or even necessary for operators to deploy and run VACM/RADIUS managed systems. In fact, there were statements to the effect that the operational need wasn't clear and that the cost of implementation might not be worth the utility; - There was not agreement as to the implementationa and operational cost of the counters/notifications but all seemed to agree that having counters/notifications would cost more than not having them; - At the end of the email chain, proponents for various counters/notifications said that they could live without them; - If we do incorporate some of the suggested counters/notifications, working through the necessary details and corner cases _might_ require some VACM changes. If this proves to be the case, it is outside of our current charter and (I believe) would significantly slow the progression of the document. Based on the above factors, my suggestion to the WG is that we not incorporate any of the counters/notifications that were discussed in mid-March and that we initiate a WG Last Call on 'Extensions to the View-based Access Control Model for use with RADIUS draft-ietf-isms-radius-vacm-05.txt' in short length of time (say about a week). Comments and suggestions are, of course, welcome. Russ From ietfdbh@comcast.net Fri May 7 07:53:13 2010 Return-Path: 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 40CD13A6B4F for ; Fri, 7 May 2010 07:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.173 X-Spam-Level: X-Spam-Status: No, score=-0.173 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_50=0.001] 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 nmGTKE90UJqL for ; Fri, 7 May 2010 07:53:12 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id 514533A6950 for ; Fri, 7 May 2010 07:52:50 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta13.westchester.pa.mail.comcast.net with comcast id EatY1e0050mv7h05DeseTB; Fri, 07 May 2010 14:52:38 +0000 Received: from Harrington73653 ([67.189.235.106]) by omta11.westchester.pa.mail.comcast.net with comcast id Eese1e00C2JQnJT3Xese59; Fri, 07 May 2010 14:52:38 +0000 From: "David Harrington" To: , References: <20100506175932267697.1f5848bb@tislabs.com> Date: Fri, 7 May 2010 10:52:35 -0400 Message-ID: <0a9701caedf4$ee6dd920$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20100506175932267697.1f5848bb@tislabs.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcrtZ20FVCtTqs1BSXWsNV6LN3ybuQAjVcyA Cc: mundy@sparta.com Subject: Re: [Isms] Proposal for progression of VACM/RADIUS ID 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: , X-List-Received-Date: Fri, 07 May 2010 14:53:13 -0000 Hi, If you do this, please make sure the shepherding document reflects that this was discussed and WG consensus was to not include the counters. That could save you time when it goes through IESG review. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of mundy@tislabs.com > Sent: Thursday, May 06, 2010 6:00 PM > To: isms@ietf.org > Cc: mundy@sparta.com > Subject: [Isms] Proposal for progression of VACM/RADIUS ID > > > Trying to come up with a way to move the VACM/RADIUS draft forward, we > obviously had a difficult time determining what and how many counters > and notifications should be included in the specification. As Juergen > pointed out, I've not been an active participant in the technical > discussions and don't have any particular positions to support or > oppose - my objective here is to identify how we should proceed > forward with the VACM/RADIUS document. > > My approach to this has been to carefully read all of the related mail > on the list (actually a couple of readings) so I could come up a > reasoned way for us to move forward. Based on these readings, a few > things of note related to counters/notifications stuck out to me: > > - No one made any strong arguments that any of these were important or > even necessary for operators to deploy and run VACM/RADIUS managed > systems. In fact, there were statements to the effect that the > operational need wasn't clear and that the cost of implementation > might not be worth the utility; > > - There was not agreement as to the implementationa and operational > cost of the counters/notifications but all seemed to agree that > having counters/notifications would cost more than not having them; > > - At the end of the email chain, proponents for various > counters/notifications said that they could live without them; > > - If we do incorporate some of the suggested counters/notifications, > working through the necessary details and corner cases _might_ > require some VACM changes. If this proves to be the case, it > is outside of our current charter and (I believe) would > significantly slow the progression of the document. > > Based on the above factors, my suggestion to the WG is that we not > incorporate any of the counters/notifications that were discussed in > mid-March and that we initiate a WG Last Call on 'Extensions to the > View-based Access Control Model for use with RADIUS > draft-ietf-isms-radius-vacm-05.txt' in short length of time (say about > a week). > > Comments and suggestions are, of course, welcome. > > > Russ > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From root@core3.amsl.com Fri May 7 13:15:07 2010 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3CF333A67FF; Fri, 7 May 2010 13:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100507201506.3CF333A67FF@core3.amsl.com> Date: Fri, 7 May 2010 13:15:02 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-dtls-tm-13.txt 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: , X-List-Received-Date: Fri, 07 May 2010 20:15:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) Author(s) : W. Hardaker Filename : draft-ietf-isms-dtls-tm-13.txt Pages : 64 Date : 2010-05-07 This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This transport model is designed to meet the security and operational needs of network administrators. It supports sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g. UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the TLS Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-dtls-tm-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-07130813.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri May 7 14:00:01 2010 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8135C3A69F8; Fri, 7 May 2010 14:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100507210001.8135C3A69F8@core3.amsl.com> Date: Fri, 7 May 2010 14:00:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-dtls-tm-14.txt 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: , X-List-Received-Date: Fri, 07 May 2010 21:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) Author(s) : W. Hardaker Filename : draft-ietf-isms-dtls-tm-14.txt Pages : 64 Date : 2010-05-07 This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This transport model is designed to meet the security and operational needs of network administrators. It supports sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g. UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the TLS Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-dtls-tm-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-07135811.I-D@ietf.org> --NextPart-- From mundy@tislabs.com Mon May 10 20:45:24 2010 Return-Path: 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 6490D28C10C for ; Mon, 10 May 2010 20:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 IzEl+8-OEocO for ; Mon, 10 May 2010 20:45:23 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 396CB28C103 for ; Mon, 10 May 2010 20:45:23 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o4B3jA3h013369; Mon, 10 May 2010 22:45:10 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o4B3jAPO007335; Mon, 10 May 2010 22:45:10 -0500 Received: from calvin.home.tislabs.com ([68.33.140.25]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 May 2010 23:45:09 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by calvin.home.tislabs.com (Postfix) with ESMTP id 4AD3B228EEFE; Mon, 10 May 2010 23:44:49 -0400 (EDT) Date: Mon, 10 May 2010 23:44:48 -0400 From: mundy@tislabs.com To: David Harrington Message-ID: <20100510234448889849.79957c2f@tislabs.com> In-Reply-To: <0a9701caedf4$ee6dd920$0600a8c0@china.huawei.com> References: <20100506175932267697.1f5848bb@tislabs.com> <0a9701caedf4$ee6dd920$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: GyazMail version 1.5.9 X-OriginalArrivalTime: 11 May 2010 03:45:09.0979 (UTC) FILETIME=[5AB4B2B0:01CAF0BC] Cc: isms@ietf.org, mundy@sparta.com Subject: Re: [Isms] Proposal for progression of VACM/RADIUS ID 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: , X-List-Received-Date: Tue, 11 May 2010 03:45:24 -0000 Hi Dave, Good suggestion, will do. Russ On Fri, 7 May 2010 10:52:35 -0400, David Harrington wrote: > Hi, > > If you do this, please make sure the shepherding document reflects > that this was discussed and WG consensus was to not include the > counters. That could save you time when it goes through IESG review. > > dbh > >> -----Original Message----- >> From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On >> Behalf Of mundy@tislabs.com >> Sent: Thursday, May 06, 2010 6:00 PM >> To: isms@ietf.org >> Cc: mundy@sparta.com >> Subject: [Isms] Proposal for progression of VACM/RADIUS ID >> >> >> Trying to come up with a way to move the VACM/RADIUS draft forward, > we >> obviously had a difficult time determining what and how many > counters >> and notifications should be included in the specification. As > Juergen >> pointed out, I've not been an active participant in the technical >> discussions and don't have any particular positions to support or >> oppose - my objective here is to identify how we should proceed >> forward with the VACM/RADIUS document. >> >> My approach to this has been to carefully read all of the related > mail >> on the list (actually a couple of readings) so I could come up a >> reasoned way for us to move forward. Based on these readings, a few >> things of note related to counters/notifications stuck out to me: >> >> - No one made any strong arguments that any of these were important > or >> even necessary for operators to deploy and run VACM/RADIUS managed >> systems. In fact, there were statements to the effect that the >> operational need wasn't clear and that the cost of implementation >> might not be worth the utility; >> >> - There was not agreement as to the implementationa and operational >> cost of the counters/notifications but all seemed to agree that >> having counters/notifications would cost more than not having > them; >> >> - At the end of the email chain, proponents for various >> counters/notifications said that they could live without them; >> >> - If we do incorporate some of the suggested counters/notifications, >> working through the necessary details and corner cases _might_ >> require some VACM changes. If this proves to be the case, it >> is outside of our current charter and (I believe) would >> significantly slow the progression of the document. >> >> Based on the above factors, my suggestion to the WG is that we not >> incorporate any of the counters/notifications that were discussed in >> mid-March and that we initiate a WG Last Call on 'Extensions to the >> View-based Access Control Model for use with RADIUS >> draft-ietf-isms-radius-vacm-05.txt' in short length of time (say > about >> a week). >> >> Comments and suggestions are, of course, welcome. >> >> >> Russ >> >> >> _______________________________________________ >> Isms mailing list >> Isms@ietf.org >> https://www.ietf.org/mailman/listinfo/isms >> From wwwrun@core3.amsl.com Wed May 12 11:35:05 2010 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 1AFF728C3BC; Wed, 12 May 2010 11:35:04 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100512183505.1AFF728C3BC@core3.amsl.com> Date: Wed, 12 May 2010 11:35:05 -0700 (PDT) Cc: Internet Architecture Board , isms mailing list , isms chair , RFC Editor Subject: [Isms] Protocol Action: 'Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)' to Proposed Standard 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: , X-List-Received-Date: Wed, 12 May 2010 18:35:05 -0000 The IESG has approved the following document: - 'Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) ' as a Proposed Standard This document is the product of the Integrated Security Model for SNMP Working Group. The IESG contact persons are Sean Turner and Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-dtls-tm-14.txt Technical Summary This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. Working Group Summary This ID is the product of the ISMS WG. The WG went over several revisions of this document and the document and all WG last call comments have been resolved. There has been strong WG consensus to publish this document as Proposed Standard. Document Quality There are two known implementations in progress of the (D)TLS Transport Model. Personnel Juergen Schoenwaelder (j.schoenwaelder@jacobs-university.de) is the document shepherd. Sean Turner is the Responsible Area Director. From j.schoenwaelder@jacobs-university.de Wed May 12 14:56:12 2010 Return-Path: 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 0C6A73A6956 for ; Wed, 12 May 2010 14:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.161 X-Spam-Level: X-Spam-Status: No, score=0.161 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_50=0.001, 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 A8LJlSKVldW8 for ; Wed, 12 May 2010 14:56:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E88B63A6914 for ; Wed, 12 May 2010 14:56:09 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 63594C0016 for ; Wed, 12 May 2010 23:55:59 +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 fKGDEIxeWBvf; Wed, 12 May 2010 23:55:58 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 52470C0004; Wed, 12 May 2010 23:55:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 45F2E120A59B; Wed, 12 May 2010 23:55:58 +0200 (CEST) Date: Wed, 12 May 2010 23:55:58 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20100512215558.GA11359@elstar.local> Mail-Followup-To: isms@ietf.org References: <20100512183505.1AFF728C3BC@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100512183505.1AFF728C3BC@core3.amsl.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Isms] Protocol Action: 'Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)' to Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 21:56:12 -0000 On Wed, May 12, 2010 at 08:35:05PM +0200, The IESG wrote: > The IESG has approved the following document: > > - 'Transport Layer Security (TLS) Transport Model for the Simple Network > Management Protocol (SNMP) ' > as a Proposed Standard > > This document is the product of the Integrated Security Model for > SNMP Working Group. This is very good news - we have completed another work item. I like to thank everybody who contributed to this document and in particular Wes for all his editing work and the fast response times during the IESG review (there were quite some comments and discusses to resolve). Lets make an effort to move the RADIUS VACM document out of the WG to the IESG now in order to complete our charter. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From root@core3.amsl.com Fri May 14 21:45:01 2010 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 949833A6908; Fri, 14 May 2010 21:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100515044501.949833A6908@core3.amsl.com> Date: Fri, 14 May 2010 21:45:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-radius-vacm-06.txt 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: , X-List-Received-Date: Sat, 15 May 2010 04:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Extensions to the View-based Access Control Model for use with RADIUS Author(s) : K. Narayan, et al. Filename : draft-ietf-isms-radius-vacm-06.txt Pages : 19 Date : 2010-05-14 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes a backward-compatible supplement to the View-based Access Control Model (VACM) for version 3 of the Simple Network Management Protocol (SNMPv3) for use with the Remote Authentication Dial-In User Service (RADIUS) or other Authentication, Authorization, and Accounting (AAA) services to provide authorization of MIB database access, and defines objects for managing this supplement. It is intended to be used in conjunction with session-oriented secure SNMP Transport Models that facilitate RADIUS authentication, such as the Secure Shell Transport Model. Comments are solicited and should be addressed to the working group's mailing list at isms@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-vacm-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-radius-vacm-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-14214348.I-D@ietf.org> --NextPart-- From randy_presuhn@mindspring.com Fri May 14 21:48:01 2010 Return-Path: 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 4305C3A67EF for ; Fri, 14 May 2010 21:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 i0iDpbtgVuoX for ; Fri, 14 May 2010 21:48:00 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 627343A6782 for ; Fri, 14 May 2010 21:48:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=AkwBS3pLZe4m2llfQkbYzDx68I+WvPbrz+DF5fBpedaDB33zKnGBGaq7jzV20tNd; 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 [99.38.145.190] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OD9Hz-0003Pf-6J for isms@ietf.org; Sat, 15 May 2010 00:47:51 -0400 Message-ID: <000901caf3e9$c5ad9f20$6801a8c0@oemcomputer> From: "Randy Presuhn" To: Date: Fri, 14 May 2010 21:47:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc7205327803528e3092ae3f9c604b5f358c5521a394d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.145.190 Subject: [Isms] Updated RADIUS / VACM i-d posted 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: , X-List-Received-Date: Sat, 15 May 2010 04:48:01 -0000 Hi - I've posted an update to the RADIUS VACM integration draft. I think I've dealt with all the comments. In several cases, as editor I've smithed some of the wordings suggested on the mailing list in order to (I hope) improve clarity / precision. PLEASE check to make sure I haven't misinterpreted the intent of your proposed wording, or goofed up in the editing process. Randy From randy_presuhn@mindspring.com Fri May 14 21:54:40 2010 Return-Path: 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 AFAD93A67EF for ; Fri, 14 May 2010 21:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.093, 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 v0ep18z7n2W6 for ; Fri, 14 May 2010 21:54:40 -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 F17DE3A67D3 for ; Fri, 14 May 2010 21:54:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=G8PoYDo0lmeO6CCoHDq8M9oJ1XOG+Ot/d2yO10hY+enIqpnJ3rETDUbQpIkvLTpr; 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 [99.38.145.190] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OD9OQ-0000HU-W0 for isms@ietf.org; Sat, 15 May 2010 00:54:31 -0400 Message-ID: <001701caf3ea$b5732700$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <000901caf3e9$c5ad9f20$6801a8c0@oemcomputer> Date: Fri, 14 May 2010 21:54:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035993e790bb81fe4686ed968dfd0c7b1b1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.145.190 Subject: Re: [Isms] Updated RADIUS / VACM i-d posted 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: , X-List-Received-Date: Sat, 15 May 2010 04:54:40 -0000 Hi - Diffs from the previous version are at http://tools.ietf.org/rfcdiff?url2=draft-ietf-isms-radius-vacm-06 If you have comments, please send them to the WG mailing list. It would help me a great deal if you include no more than one issue per message (with an appropriate subject line) unless it's a batch of trivial typos. Randy From j.schoenwaelder@jacobs-university.de Sat May 15 03:08:59 2010 Return-Path: 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 7718D3A66B4 for ; Sat, 15 May 2010 03:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.163 X-Spam-Level: X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_50=0.001, 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 mq5XRwdF-xnx for ; Sat, 15 May 2010 03:08: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 116BC3A6907 for ; Sat, 15 May 2010 03:08:57 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id EEEA2C000F for ; Sat, 15 May 2010 12:08:47 +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 FfuRRBczpvnf; Sat, 15 May 2010 12:08:46 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 59591C0011; Sat, 15 May 2010 12:08:46 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 31549120D3EB; Sat, 15 May 2010 12:08:44 +0200 (CEST) Date: Sat, 15 May 2010 12:08:44 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20100515100842.GB215@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Isms] last call to check the changes of the radius / vacm document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 10:08:59 -0000 The RADIUS / VACM document was last called March 8-22. The last call discussion resulted into several relatively minor changes now incorporated in . This message starts a 7-day last call to verify the changes made in the revised version. The document can be found here: http://tools.ietf.org/html/draft-ietf-isms-radius-vacm-06 The changes can be found here: http://tools.ietf.org/rfcdiff?url2=draft-ietf-isms-radius-vacm-06 Please post any issues you have with the changes to the WG mailing list by May 22nd. Silence will be interpreted as support for the changes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sat May 15 03:10:57 2010 Return-Path: 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 A24233A66B4 for ; Sat, 15 May 2010 03:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_50=0.001, 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 AKsjUvUGuTcZ for ; Sat, 15 May 2010 03:10:55 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 7D6223A69F2 for ; Sat, 15 May 2010 03:10:46 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6813EC0011 for ; Sat, 15 May 2010 12:10: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 HuekvFx+B4zy; Sat, 15 May 2010 12:10:36 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5BB89C000F; Sat, 15 May 2010 12:10:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4BE27120D4AD; Sat, 15 May 2010 12:10:36 +0200 (CEST) Date: Sat, 15 May 2010 12:10:36 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20100515101036.GA566@elstar.local> Mail-Followup-To: isms@ietf.org References: <20100515100842.GB215@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100515100842.GB215@elstar.local> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Isms] last call to check the changes of the radius / vacm document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 10:10:58 -0000 On Sat, May 15, 2010 at 12:08:44PM +0200, Juergen Schoenwaelder wrote: > Please post any issues you have with the changes to the WG mailing > list by May 22nd. Silence will be interpreted as support for the > changes. I spotted one editorial nit: s/GroupName, which is identifies/GroupName, which identifies/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Sat May 15 10:58:53 2010 Return-Path: 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 5FC8E3A696B for ; Sat, 15 May 2010 10:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.277 X-Spam-Level: X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001] 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 62rZFK6V6U1h for ; Sat, 15 May 2010 10:58:52 -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 881083A67A2 for ; Sat, 15 May 2010 10:58:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=XuyeFNkrinNjHkFnHXEuPEbIzb7+LmKQgxxYhflIwFnSivPoFuORmT8PyiRieCNs; 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 [99.33.93.151] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ODLdL-0007WH-F5 for isms@ietf.org; Sat, 15 May 2010 13:58:43 -0400 Message-ID: <000a01caf458$48c5c360$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100515100842.GB215@elstar.local> <20100515101036.GA566@elstar.local> Date: Sat, 15 May 2010 10:58:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035a954833d089d6a429d5ee005351b262e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.93.151 Subject: Re: [Isms] last call to check the changes of the radius / vacmdocument 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: , X-List-Received-Date: Sat, 15 May 2010 17:58:53 -0000 Hi - > From: "Juergen Schoenwaelder" > To: > Sent: Saturday, May 15, 2010 3:10 AM > Subject: Re: [Isms] last call to check the changes of the radius / vacmdocument ... > I spotted one editorial nit: > > s/GroupName, which is identifies/GroupName, which identifies/ Thank you. I've applied the correction to the xml source file. Randy From randy_presuhn@mindspring.com Wed May 26 18:55:36 2010 Return-Path: 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 BB3753A67EF for ; Wed, 26 May 2010 18:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 f7iIZH1hb5+R for ; Wed, 26 May 2010 18:55:36 -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 1621D3A6847 for ; Wed, 26 May 2010 18:55:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=a2BcvewTcMCkWrTacqP9kWuZNqLNRZ6RGg/cBHFcTVP2F+Yr7k7sQp3qky44Q6wa; 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 [99.60.26.223] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OHSJi-0007qw-R7 for isms@ietf.org; Wed, 26 May 2010 21:55:27 -0400 Message-ID: <001801cafd3f$c2814860$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100515100842.GB215@elstar.local> Date: Wed, 26 May 2010 18:56:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a91fc72053278035d21324c57d49ab36b17d5730e1e53467350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.60.26.223 Subject: Re: [Isms] last call to check the changes of the radius / vacm document 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: , X-List-Received-Date: Thu, 27 May 2010 01:55:36 -0000 Hi - > From: "Juergen Schoenwaelder" > To: > Sent: Saturday, May 15, 2010 3:08 AM > Subject: [Isms] last call to check the changes of the radius / vacm document ... > Please post any issues you have with the changes to the WG mailing > list by May 22nd. Silence will be interpreted as support for the > changes. I've received a total of 1 comment, a request for a typo fix. I've applied the correction to my XML source, and can generate an updated draft whenever you like. Let me know how you'd like me to procede. Randy From dnelson@elbrys.com Wed May 26 19:18:09 2010 Return-Path: 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 737DB3A6899 for ; Wed, 26 May 2010 19:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.117 X-Spam-Level: X-Spam-Status: No, score=-4.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 vero5Se0-hxB for ; Wed, 26 May 2010 19:18:08 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by core3.amsl.com (Postfix) with SMTP id 444173A6A97 for ; Wed, 26 May 2010 19:18:02 -0700 (PDT) Received: from source ([209.85.160.179]) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKS/3WTMOgGdOETgNN6nSpr5i7VvQvhyPZ@postini.com; Wed, 26 May 2010 19:17:53 PDT Received: by mail-gy0-f179.google.com with SMTP id 10so3804525gyd.24 for ; Wed, 26 May 2010 19:17:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.176.74 with SMTP id bd10mr8368360ibb.38.1274926668277; Wed, 26 May 2010 19:17:48 -0700 (PDT) Received: by 10.231.173.84 with HTTP; Wed, 26 May 2010 19:17:48 -0700 (PDT) In-Reply-To: <001801cafd3f$c2814860$6801a8c0@oemcomputer> References: <20100515100842.GB215@elstar.local> <001801cafd3f$c2814860$6801a8c0@oemcomputer> Date: Wed, 26 May 2010 22:17:48 -0400 Message-ID: From: Dave Nelson To: Randy Presuhn Content-Type: multipart/alternative; boundary=0016363b8c102d6e1d048789ffaa Cc: isms@ietf.org Subject: Re: [Isms] last call to check the changes of the radius / vacm document 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: , X-List-Received-Date: Thu, 27 May 2010 02:18:09 -0000 --0016363b8c102d6e1d048789ffaa Content-Type: text/plain; charset=ISO-8859-1 In order to be pro-active, I should indicate that I've reviewed the latest draft and see no problems with the changes it incorporates. --0016363b8c102d6e1d048789ffaa Content-Type: text/html; charset=ISO-8859-1 In order to be pro-active, I should indicate that I've reviewed the latest draft and see no problems with the changes it incorporates.
--0016363b8c102d6e1d048789ffaa-- From j.schoenwaelder@jacobs-university.de Wed May 26 23:18:00 2010 Return-Path: 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 64DE73A6818 for ; Wed, 26 May 2010 23:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 LRDW+06NVwB6 for ; Wed, 26 May 2010 23:17: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 C92F03A6837 for ; Wed, 26 May 2010 23:17:58 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 78151C000C; Thu, 27 May 2010 08:17:49 +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 MpQ1wcqP+283; Thu, 27 May 2010 08:17:48 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C77A3C0010; Thu, 27 May 2010 08:17:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8871D125D616; Thu, 27 May 2010 08:17:47 +0200 (CEST) Date: Thu, 27 May 2010 08:17:47 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20100527061747.GB5882@elstar.local> Mail-Followup-To: Randy Presuhn , "isms@ietf.org" References: <20100515100842.GB215@elstar.local> <001801cafd3f$c2814860$6801a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001801cafd3f$c2814860$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] last call to check the changes of the radius / vacm document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 06:18:00 -0000 On Thu, May 27, 2010 at 03:56:00AM +0200, Randy Presuhn wrote: > Hi - > > > From: "Juergen Schoenwaelder" > > To: > > Sent: Saturday, May 15, 2010 3:08 AM > > Subject: [Isms] last call to check the changes of the radius / vacm document > ... > > Please post any issues you have with the changes to the WG mailing > > list by May 22nd. Silence will be interpreted as support for the > > changes. > > I've received a total of 1 comment, a request for a typo fix. > I've applied the correction to my XML source, and can generate > an updated draft whenever you like. Let me know how you'd like > me to procede. Just keep the typo fix in your xml source; there might be a need for another revision later on in the process when this document hits the IESG. Since nobody raised substantial comments, I have an action item now to produce a document writeup and then we can take this document to our AD. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Thu May 27 10:18:59 2010 Return-Path: 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 78C3D3A68D7 for ; Thu, 27 May 2010 10:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 9YR8nx3TiDZ5 for ; Thu, 27 May 2010 10:18:57 -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 C2CCB3A6B3C for ; Thu, 27 May 2010 10:18:56 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta08.westchester.pa.mail.comcast.net with comcast id NaVH1e00A1ei1Bg58hJozi; Thu, 27 May 2010 17:18:48 +0000 Received: from Harrington73653 ([207.59.110.215]) by omta24.westchester.pa.mail.comcast.net with comcast id NhJV1e00A4eszMr3khJXVj; Thu, 27 May 2010 17:18:46 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'Randy Presuhn'" References: <20100515100842.GB215@elstar.local><001801cafd3f$c2814860$6801a8c0@oemcomputer> <20100527061747.GB5882@elstar.local> Date: Thu, 27 May 2010 13:18:25 -0400 Message-ID: <00e601cafdc0$a8f495b0$dfb611ac@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20100527061747.GB5882@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acr9Zz4rAsxlsosOQUeYrEefyVBJHwAK+1Bw Cc: isms@ietf.org Subject: Re: [Isms] last call to check the changes of the radius / vacm document 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: , X-List-Received-Date: Thu, 27 May 2010 17:18:59 -0000 Whoops. running late... I am thrilled to see this document getting close to submission. I think this is trememdously important specification to simplify SNMP authentication and access control. Unfortunately, this document repeatedly ignores RFC3411 modularity, creates unnecessary dependencies between models, and ignores which model has access to which information. In some cases, I think the text as written could not be implemented in a manner that is consistent with RFC3411 modularity. These need to be corrected. 1) section 1: "In this environment:" starts a list of specific choices of modules. This is not consistent with the SNMPv3 approach of "model agility" - ensuring different models could be used together and updated independently of other models in use. For example, an SNMPv4 message format could be developed, and such a messaging model could be used in place of SNMPv3 message format. A new transport-aware security model could provide comparable capabilities to TSM. It is inappropriate for one model to require specific other models, but not inappropriate to recommend/require specific properties for related models. It is up to administrators to ensure that the models are deployed in appropriate conbinations (and the specifications should provide deployment recommendations). This section should be rewritten to specify the properties expected, with suggestions for models that provide those properties. I think this can be compared to security algorithm agility - "here is the threat, and here is the currently recommended mitigation" vs. "DES is used to provide security." Obviously, this specification MUST be used with the VACM model and RFC5608 since it extends the VACM model with information from RFC5608 attributes. However, it is NOT a requirement that this be used with only SNMPv3 messages, TSM, or SSH. Section 1 makes it appear this specification can only work in an environment with those models. 2) section 4.2, paragraph 2 discusses the need to bind the authenticated principal with the identity used for access control. It implies SNMP does not provide such a binding. RFC3411 explicitly provides such a binding - the securityName output of the security model is expected to be used as the identity in access control decisions (via the isAccessAllowed ASI). It was a deliberate design decision to separate the underlying authetication algorithmic mechanism, e.g. SSH username, from the access control configuration by passing a security-algorithm-independent securityName from the security subsystem that could be used to configure the access control subsystem (using the access-control-model-independent securityName). securityModel/securityName provides a binding while avoiding model-specific dependencies. 3) section 4.3 This is a list of requirements that must be met by transport security models. Security models SHOULD NOT have these features. These are secure transport properties, that can be recognized and handled by associated transport models, but never by security models. The security subsystem has no notion of session. RFC5990 and 5991 are quite explicit about this. TSM has no session, so even TSM would not meet this requirement. As described in RFC5991, not all secure transports support a notion of session; some have a notion of channels or something similar. 4) I think you may want to clarify this further. You might want to say the secure transport used must have a notion of session to which AAA authentication and authorization can be bound. 5) a security model should never provide an indication of the end of a specific transport session. Only the transport model should be aware of the transport session (unless your design will include a model-independent indication that gets shared somehow, such as via a MIB). 6) section 7.1 - I don't understand what this says. I am not certain what is meant by "The security model SHOULD bind principal identity to access control policy via an external AAA server, as the Transport Security Model does." RFC5591 defines TSM, and the only mention of AAA is a warning not to rely on AAA in times of network stress. The modularity of RFC3411 actually argues against having the security model know anything about the access control policies. AC policies are defined **within** an access control model (see RFC3411 A.4), and the binding between a securityName and a policy (e.g. groupname) is **deliberately** done AFTER the isAccessAllowed ASI is called (inside the access control subsystem). This approach allows for group-based policies ala the VACM model, and allows models that use other types of policies, such as a UNIX-style user-group-all rrw hierarchies. In fact, the security model NEVER communicates directly with the access control subsystem in the RFC3411 architecture; the security model passes securityName to the application subsystem, which presumably passes the same securityName to the access control subsystem via isAccessAllowed. This was a deliberate decision made by the SNMPv3 WG in the design of the RFC3411 architecture. 7) section 7.2 it is unclear to me which subsystem is doing the processing involved. I am not sure any model has all the information at the same time. 8) 7.2.1 s/a new secure transport model session has been established/ s/a new transport session has been established/ I recommend referring to the transport model as the "Transport Model" rather than "Secure Transport Model", to avoid confusion with "Transport Security Model". 9) 7.2.3 It is unclear what "the value of an instance of extGroupName is updated" means. This is in a received communication from RADIUS? How does one determine what a corresponding entry is? 10) 7.3 a transport model session never ends; transport sessions do. "is provided to this function" - what function? "session ... within the scope of that SecurityModel" - what security model? sessions do not exist within security models. 11) section 8 I'm not crazy about long object names, but this module has been named snmpExtVacmMIB; all the objects with an extVacm prefix should be updated, and text references to them should be updated, to be consistent with RFC4181 conventions. I didn't go through the whole MIB looking for grammar and modularity problems. I spotted grammar issues in the first DESCRIPTION clause (extVacmSecurityToGroupTable), and modularity in the second (extVacmSecurityToGroupEntry). Randy, can you please look the DESCRIPTION clauses over closely? 12) extVacmSecurityToGroupEntry - entries in extVacmTable do not persist. section 7.3.2 say that the vacmTable entry should be removed when no extVacmTable entries exist. So do the corresponding vacmTabel entries also not persist? 13) extVacmSecurityModel - security models don't have sessions. 14) in this case, doesn't this specifally need to come from the RADIUS Management-Policy-ID? Ergo, this is not really an example; it is a requirement. If the purpose of saying this is an example is to allow for other AAA, then other places in the text that mention only RADIUS need updating. 15) In section 9, I think the first paragraph could be much more succinct, and clearer: OLD: The algorithms in this memo make heuristic use of the StorageType of entries in the vacmSecurityToGroupTable to distinguish those provisioned by a security administrator (which would presumably not be configured as "volatile") from those dynamically generated. In making this distinction, it assumes that those entries explicitly provisioned by a security administrator and given a non-"volatile" status are not to be dynamically over-ridden. Users of this memo need to be aware of this operational assumption, which, while reasonable, is not necessarily universally valid. For example, this situation could also occur if the SNMP security administrator had mistakenly created these non-volatile entries in error. NEW: The algorithms in this memo make heuristic use of the StorageType of entries in the vacmSecurityToGroupTable to distinguish entries provisioned by a security administrator from those dynamically generated. Entries given a status other than "volatile" are assumed to be deliberately provisioned by a security administrator to override centralized AAA policy. See 7.2.2 for details. 16) section 9 OLD: o Entries for the vacmSecurityToGroup table corresponding to a given security model are created only through the operation of the procedures described in this memo. A consequence of this would be NEW: o In the first approach, entries for the vacmSecurityToGroup table corresponding to a given security model are created only through the operation of the procedures described in this memo. A consequence of this would be rationale: it needs to be clear that this is describing only the first entry-creation approach, not the general case. We need to be clear that this is a deployment decision, not a REQUIREMENT of the vacm/radius extension. You might also be able to clarify this by using numbers rather than symbols for the bullets. 17) I found this section describing the approaches rather confusing. The langugae is not very tight. For example, what does "inconsistent re-use of the same name for different entities or individuals (principals)" mean? I think this could be simplified by using consistent langauge; we already know what prinisipal standards for, we don't really need to re-specify the "entities or individuals" again. I assume the "same name" means the same securityModel/securityName since that is what we deal with here. But it is an INDEX value, so doesn't that guarantee uniqueness? If we are talking about the same, for example, SSH user name, the uniqueness should be provided by the transport model. So whihc "same name" use cases are we talking about here? I think some example tables would be helpful, to show what would happen when certain new entries are called for by new extVacm fields to be used to create new extVacmTable entries. 18) o extVacmGroupName - since this identifies a security policy and associates it with a particular user, this is potentially sensitive. No it doesn't; this object only identifies the policy; it is the table entry that associates it with a principal. 19) RFC5591 should not be normative. I don't think there is anything specific inside rfc5591 that must be known to understand this document, and except for the Intro, 5591 and TSM and "Transport Security Model" are only mentioned where I argue it is incorrect. Again sorry for being slow. I hope this review helps get the document through the approval process faster. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Thursday, May 27, 2010 2:18 AM > To: Randy Presuhn > Cc: isms@ietf.org > Subject: Re: [Isms] last call to check the changes of the > radius / vacm document > > On Thu, May 27, 2010 at 03:56:00AM +0200, Randy Presuhn wrote: > > Hi - > > > > > From: "Juergen Schoenwaelder" > > > > To: > > > Sent: Saturday, May 15, 2010 3:08 AM > > > Subject: [Isms] last call to check the changes of the > radius / vacm document > > ... > > > Please post any issues you have with the changes to the WG mailing > > > list by May 22nd. Silence will be interpreted as support for the > > > changes. > > > > I've received a total of 1 comment, a request for a typo fix. > > I've applied the correction to my XML source, and can generate > > an updated draft whenever you like. Let me know how you'd like > > me to procede. > > Just keep the typo fix in your xml source; there might be a need for > another revision later on in the process when this document hits the > IESG. > > Since nobody raised substantial comments, I have an action item now to > produce a document writeup and then we can take this document to our > AD. > > /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 dnelson@elbrys.com Thu May 27 10:51:38 2010 Return-Path: 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 D40153A6845 for ; Thu, 27 May 2010 10:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 q9+yOMISsfhp for ; Thu, 27 May 2010 10:51:38 -0700 (PDT) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by core3.amsl.com (Postfix) with SMTP id DBA463A6403 for ; Thu, 27 May 2010 10:51:37 -0700 (PDT) Received: from source ([209.85.160.51]) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKS/6xIBYXdpJI54eQYYLrZ9Khzy/iw35Y@postini.com; Thu, 27 May 2010 10:51:29 PDT Received: by pwj9 with SMTP id 9so178189pwj.24 for ; Thu, 27 May 2010 10:51:28 -0700 (PDT) Received: by 10.142.3.26 with SMTP id 26mr139093wfc.165.1274982687998; Thu, 27 May 2010 10:51:27 -0700 (PDT) Received: from dbn-imac.elbrysnetworks.com (host171.elbrysnetworks.com [64.140.243.171]) by mx.google.com with ESMTPS id w39sm789826wfh.15.2010.05.27.10.51.26 (version=SSLv3 cipher=RC4-MD5); Thu, 27 May 2010 10:51:27 -0700 (PDT) Message-Id: <871A33FE-B5C6-4CC2-9354-997CDBD9E8BF@elbrys.com> From: "David B. Nelson" To: "David Harrington" In-Reply-To: <00e601cafdc0$a8f495b0$dfb611ac@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 May 2010 13:51:25 -0400 References: <20100515100842.GB215@elstar.local><001801cafd3f$c2814860$6801a8c0@oemcomputer> <20100527061747.GB5882@elstar.local> <00e601cafdc0$a8f495b0$dfb611ac@china.huawei.com> X-Mailer: Apple Mail (2.936) Cc: isms@ietf.org Subject: Re: [Isms] last call to check the changes of the radius / vacm document 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: , X-List-Received-Date: Thu, 27 May 2010 17:51:38 -0000 On May 27, 2010, at 1:18 PM, David Harrington wrote: > Whoops. running late... > > Unfortunately, this document repeatedly ignores RFC3411 modularity, > creates unnecessary dependencies between models, and ignores which > model has access to which information. In some cases, I think the text > as written could not be implemented in a manner that is consistent > with RFC3411 modularity. These need to be corrected. I'll need a block of time to study and reply to Dave's commentary. I like the opportunity to do that before we make changes to the draft. While I'm sympathetic to the notion of maintaining the RFC3411 modularity, I'm not convinced it's completely possible when it comes to the Security Subsystem. While it may be possible to implement a Security Model in a way that honors RFC3411 and would work with a session-based AAA system such as RADIUS, I believe that no such models exist. Unfortunately, think that in choosing an "end-around" approach to a thorny problem, and simply "outsourcing" security to the Transport Subsystem, we've effectively caused many of the modularity violations that Dave points out. Now, I realize that "them's fightin' words", so I'll need some time to work through Dave's comments and see where fully general modularity can be introduced into this document, and where it simply can't, unless we want to revisit the decisions that led to the TM and TSM that we are building upon. While the "last call" is over, I'll need an extension to digest and respond to all this material From ietfdbh@comcast.net Thu May 27 11:06:29 2010 Return-Path: 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 E75B93A6BE1 for ; Thu, 27 May 2010 11:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 D0bAPKaSpnRs for ; Thu, 27 May 2010 11:06:29 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id A27573A6BD7 for ; Thu, 27 May 2010 11:06:12 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta01.westchester.pa.mail.comcast.net with comcast id NcQl1e0041GhbT851i64QL; Thu, 27 May 2010 18:06:04 +0000 Received: from Harrington73653 ([207.59.110.215]) by omta07.westchester.pa.mail.comcast.net with comcast id Ni5m1e0024eszMr3Ti5o9b; Thu, 27 May 2010 18:06:01 +0000 From: "David Harrington" To: "'David B. Nelson'" References: <20100515100842.GB215@elstar.local><001801cafd3f$c2814860$6801a8c0@oemcomputer> <20100527061747.GB5882@elstar.local> <00e601cafdc0$a8f495b0$dfb611ac@china.huawei.com> <871A33FE-B5C6-4CC2-9354-997CDBD9E8BF@elbrys.com> Date: Thu, 27 May 2010 14:05:45 -0400 Message-ID: <010301cafdc7$43ab9d00$dfb611ac@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <871A33FE-B5C6-4CC2-9354-997CDBD9E8BF@elbrys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acr9xTyQ0hjlqkutRPOs0LY7A3f1WwAAJL7A Cc: isms@ietf.org Subject: Re: [Isms] last call to check the changes of the radius / vacm document 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: , X-List-Received-Date: Thu, 27 May 2010 18:06:30 -0000 Hi, Let me be clear. I think most of the problems I cite are not about the difference between the RADIUS philosophy and the SNMPv3 philosophy. Many of the problems are actually editorial problems, where the text says "security model" when it should have said "transport model". and the text just doesn't keep a clear distinction between them. Often it is unclear which subsystem is expected to do something that needs doing. The text just needs to be "tightened". In some cases, further debate might be needed, but I think we have consensus about the "in the background" approach. It needs to be described more accurately. dbh > -----Original Message----- > From: David B. Nelson [mailto:dnelson@elbrys.com] > Sent: Thursday, May 27, 2010 1:51 PM > To: David Harrington > Cc: 'Juergen Schoenwaelder'; 'Randy Presuhn'; isms@ietf.org > Subject: Re: [Isms] last call to check the changes of the > radius / vacm document > > On May 27, 2010, at 1:18 PM, David Harrington wrote: > > > Whoops. running late... > > > > Unfortunately, this document repeatedly ignores RFC3411 modularity, > > creates unnecessary dependencies between models, and ignores which > > model has access to which information. In some cases, I > think the text > > as written could not be implemented in a manner that is consistent > > with RFC3411 modularity. These need to be corrected. > > I'll need a block of time to study and reply to Dave's > commentary. I > like the opportunity to do that before we make changes to the > draft. > While I'm sympathetic to the notion of maintaining the RFC3411 > modularity, I'm not convinced it's completely possible when it comes > to the Security Subsystem. While it may be possible to implement a > Security Model in a way that honors RFC3411 and would work with a > session-based AAA system such as RADIUS, I believe that no > such models > exist. Unfortunately, think that in choosing an "end-around" > approach > to a thorny problem, and simply "outsourcing" security to the > Transport Subsystem, we've effectively caused many of the modularity > violations that Dave points out. > > Now, I realize that "them's fightin' words", so I'll need > some time to > work through Dave's comments and see where fully general modularity > can be introduced into this document, and where it simply can't, > unless we want to revisit the decisions that led to the TM and TSM > that we are building upon. > > While the "last call" is over, I'll need an extension to digest and > respond to all this material > > From dnelson@elbrys.com Thu May 27 11:15:18 2010 Return-Path: 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 4EB163A680B for ; Thu, 27 May 2010 11:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 9XDcultvaxwt for ; Thu, 27 May 2010 11:15:11 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id B9E9B3A67EE for ; Thu, 27 May 2010 11:15:09 -0700 (PDT) Received: from source ([74.125.83.169]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKS/62opW09G4VFQtdoD4eVAhCq69TUIFC@postini.com; Thu, 27 May 2010 11:15:00 PDT Received: by mail-pv0-f169.google.com with SMTP id 21so229833pvc.0 for ; Thu, 27 May 2010 11:14:58 -0700 (PDT) Received: by 10.141.22.14 with SMTP id z14mr8233423rvi.135.1274984098674; Thu, 27 May 2010 11:14:58 -0700 (PDT) Received: from dbn-imac.elbrysnetworks.com (host171.elbrysnetworks.com [64.140.243.171]) by mx.google.com with ESMTPS id d14sm1274655rva.18.2010.05.27.11.14.57 (version=SSLv3 cipher=RC4-MD5); Thu, 27 May 2010 11:14:58 -0700 (PDT) Message-Id: From: "David B. Nelson" To: "David Harrington" In-Reply-To: <010301cafdc7$43ab9d00$dfb611ac@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 27 May 2010 14:14:55 -0400 References: <20100515100842.GB215@elstar.local><001801cafd3f$c2814860$6801a8c0@oemcomputer> <20100527061747.GB5882@elstar.local> <00e601cafdc0$a8f495b0$dfb611ac@china.huawei.com> <871A33FE-B5C6-4CC2-9354-997CDBD9E8BF@elbrys.com> <010301cafdc7$43ab9d00$dfb611ac@china.huawei.com> X-Mailer: Apple Mail (2.936) Cc: isms@ietf.org Subject: Re: [Isms] last call to check the changes of the radius / vacm document 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: , X-List-Received-Date: Thu, 27 May 2010 18:15:18 -0000 On May 27, 2010, at 2:05 PM, David Harrington wrote: > Many of the problems are actually editorial problems, where the text > says "security model" when it should have said "transport model". and > the text just doesn't keep a clear distinction between them. Often it > is unclear which subsystem is expected to do something that needs > doing. The text just needs to be "tightened". That would be nice. Since you've suggest that sections be rewritten, without supplying the suggested, text, I think some time is needed to work out and review suggested text. From j.schoenwaelder@jacobs-university.de Thu May 27 22:56:45 2010 Return-Path: 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 A5BA93A68A4 for ; Thu, 27 May 2010 22:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 m8d9mAMd+hBH for ; Thu, 27 May 2010 22:56:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8A5433A67D1 for ; Thu, 27 May 2010 22:56:44 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 534A2C000C; Fri, 28 May 2010 07:56:34 +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 vxu2pAY4lxLS; Fri, 28 May 2010 07:56: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 3772EC0019; Fri, 28 May 2010 07:56:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0106C125FA31; Fri, 28 May 2010 07:56:31 +0200 (CEST) Date: Fri, 28 May 2010 07:56:31 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20100528055631.GA8690@elstar.local> Mail-Followup-To: David Harrington , 'Randy Presuhn' , "isms@ietf.org" References: <20100515100842.GB215@elstar.local> <001801cafd3f$c2814860$6801a8c0@oemcomputer> <20100527061747.GB5882@elstar.local> <00e601cafdc0$a8f495b0$dfb611ac@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00e601cafdc0$a8f495b0$dfb611ac@china.huawei.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "isms@ietf.org" Subject: Re: [Isms] last call to check the changes of the radius / vacm document X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 05:56:45 -0000 On Thu, May 27, 2010 at 07:18:25PM +0200, David Harrington wrote: > The modularity of RFC3411 actually argues against having the security > model know anything about the access control policies. AC policies are > defined **within** an access control model (see RFC3411 A.4), and the > binding between a securityName and a policy (e.g. groupname) is > **deliberately** done AFTER the isAccessAllowed ASI is called (inside > the access control subsystem). This approach allows for group-based > policies ala the VACM model, and allows models that use other types of > policies, such as a UNIX-style user-group-all rrw hierarchies. In > fact, the security model NEVER communicates directly with the access > control subsystem in the RFC3411 architecture; the security model > passes securityName to the application subsystem, which presumably > passes the same securityName to the access control subsystem via > isAccessAllowed. This was a deliberate decision made by the SNMPv3 WG > in the design of the RFC3411 architecture. David, you understand very well that the RADIUS AAA exchange happens at a processing stage where VACM is not yet involved and as a consequence RFC 3411 purity a la "there is only a model independent securityName" simply does not work. The WG (and I believe also you) agreed that the RADIUS supplied group name is passed into VACM via some implementation specific mechanism. I like to ask you explicitely whether you still support that concensus. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Fri May 28 10:29:18 2010 Return-Path: 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 E9DBE3A68B0 for ; Fri, 28 May 2010 10:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 owk9LvRBO74G for ; Fri, 28 May 2010 10:29:17 -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 8D4393A67F2 for ; Fri, 28 May 2010 10:29:17 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta04.westchester.pa.mail.comcast.net with comcast id NzZl1e00B1uE5Es545V8sW; Fri, 28 May 2010 17:29:08 +0000 Received: from Harrington73653 ([67.189.235.106]) by omta16.westchester.pa.mail.comcast.net with comcast id P5V71e00K2JQnJT3c5V7aS; Fri, 28 May 2010 17:29:08 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" References: <20100515100842.GB215@elstar.local> <001801cafd3f$c2814860$6801a8c0@oemcomputer> <20100527061747.GB5882@elstar.local> <00e601cafdc0$a8f495b0$dfb611ac@china.huawei.com> <20100528055631.GA8690@elstar.local> Date: Fri, 28 May 2010 13:29:05 -0400 Message-ID: <01b701cafe8b$461b1650$dfb611ac@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20100528055631.GA8690@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acr+KojCm3ks7/5JQGCi2u6Fei32swAVYRXw Cc: isms@ietf.org Subject: Re: [Isms] last call to check the changes of the radius / vacm document 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: , X-List-Received-Date: Fri, 28 May 2010 17:29:19 -0000 Hi, Executive Summary: Yes. I **strongly support** an implementation-specific mechanism for passing authorization and transport session data from the transport security use of AAA in the transport model into the VACM model. When this document goes to IESG Review, I will recuse myself (http://www.ietf.org/iesg/voting-procedures.html) because I have been involved in the development of the technology design, have contributed to the current document, and authored some of the RFC341x and RFC559x documents with which I find this document in conflict. So if anybody thinks I am threatening to block this document, you can think again. If I did not recuse myself, I would vote "YES" because I think this proposal is very important. Detailed Response: I strongly support this approach because using such an approach does not require that the ASIs be changed to support passing AAA authorization information in ASI parameters (or caches). I think requiring such changes in the ASIs would require re-opening almost all the SNMPv3 documents, which could destabilize SNMPv3, and would make the updated RFC341x and RFC559x documents very difficult to work with in the future. When I look at documents developed elsewhere in the IETF, few are constrained to such a tight architecture as RFC3411, and many have complained about the tight constraints, including myself. It is my impression, however, that almost all who gripe (especially implementers) also reach the conclusion that in the long run the constraints have actually been very helpful and the RFC3411 architecture should remain as a guiding principle in SNMP standards design. I have significant knowledge in this space, as RFC3411 co-author and as co-chair of the SNMPv3 WG which had strong consensus to use the RFC341x modular architecture for the SNMPv3 standard. Most of my review is about pointing out the discrepancies between SNMPv3 WG consensus and this document, whose current text I think actually does NOT do a good job of representing ISMS WG consensus. The IESG will certainly look at two major points that they usually look at. 1) whether the document is consistent with the general design principles for the protocol being modified, and 2) whether the document fits within the constraints placed on the WG during IESG charter approval. My biggest concern with the current document is that the document is rather sloppy about maintaining the data hiding aspects of RFC3411 modularity. For example, there are a number of instances where the document says that the **security model** does something with a piece of information, when the security model explicitly does not have access to that information according to RFC341x and RFC559x. I pointed out a number of other modularity/clarity issues in my review. I think this "sloppiness" is not a matter of poor work ethic; I think all the editors have done very good work. However, the original authors are RADIUS guys, indoctrinated in RADIUS concepts and RADIUS-speak, and they are not SNMP-guys indoctrinated in the RFC341x concepts and wordsmithing. So some wordsmithing errors crept in. If this document were submitted to the IESG in its current form, I think it would draw many discusses from other IESG members ***because it is inconsistent with the RFC341x and RFC559x documents***, and with the charter constraints. I will fight for the right of this WG to reach consensus to use an implementation-specific approach to bypassing the ASIs. I will not fight for the right of the WG to produce documents that are inconsistent with other documents in the set of SNMP documents. I have been very busy getting acclimated to my new role and have not had the time to participate actively in the WG lately, and as a result was delayed on doing a WGLC review. I apologize for th ekateness o fmy review. I debated whether to do my review now, or during IETF Last Call or during IESG review. I prefer to use the choice that provides the least amount of late surprise, the least amount of authority, and the least number of DISCUSSes to be resolved during IESG Review. I choose to provide this review as early as possible so you can try to fix the problems BEFORE submitting the document to the IESG. My review is done as a WG member, and I will recuse myself in IESG balloting for this document. The WG can choose to totally ignore my review if you want. However, I think the comments have substance, and I think it likely your AD and the rest of the IESG will not just ignore the comments, and the WG will have a hard job of getting IESG Approval for the document as written. I think this is an important document, and want to see it approved as quickly as possible. My review was to alert the WG to issues of consistency with RFC341x and RFC559x that I believe should be addressed so that IESG Review will be made easier. dbh > -----Original Message----- > From: Juergen Schoenwaelder > > David, > > you understand very well that the RADIUS AAA exchange happens at a > processing stage where VACM is not yet involved and as a consequence > RFC 3411 purity a la "there is only a model independent securityName" > simply does not work. The WG (and I believe also you) agreed that the > RADIUS supplied group name is passed into VACM via some implementation > specific mechanism. I like to ask you explicitely whether you still > support that concensus. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >