idnits 2.17.1 draft-ietf-snmpv3-as-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Downref: Normative reference to an Informational RFC: RFC 2316 -- Possible downref: Non-RFC (?) normative reference: ref. 'DESCRACK' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Steven M. Bellovin 3 draft-ietf-snmpv3-as-00.txt Randy Bush 4 2001.12.26 AT&T Research 6 Applicability Statement for SNMPv3 Cryptographic Algorithms 8 Copyright (C) The Internet Society (2002). All Rights Reserved. 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 0. Abstract 31 This document attempts to put in perspective the use of cryptographic 32 algorithms in the Simple Network Monitoring Protocol Version 3 33 standard. In particular, it notes that today's standard is 34 infinitely more secure than previous versions, as the previous 35 versions had zero security. It further notes that, as cryptographic 36 algorthim developments change over time, we expect that the 37 recommended algorithms will change when the security community has 38 reached new consensus. 40 1. The Current Standard is Infinitely Better 42 SNMPv1 [RFC1157] and SNMPv2c [RFC1901] SNMP transmitted community 43 strings, analogous to passwords, as cleartext over the internet. 44 This is clearly against common sense as well as the prescription in 45 [RFC2316]. 47 INTERNET-DRAFT AS for SNMPv3 Cryptographic Algorithms 2002.02.22 49 But, we also note that single-DES, as used in the SNMPv3 privacy 50 protocols, is a very old cryptographic algorithm, and cryptographic 51 algorithms do not improve with age [DESCRACK]. Moore's Law means 52 algorithims become more vulnerable to computational attacks over 53 time. And mathematical analysis of any algorithm over time tends to 54 reveal weaknesses previously missed. 56 2. The Standard Allows for Change 58 Having the foresight to anticipate advances in cryptography, the 59 SNMPv3 standard allows for future additions of new cryptographic 60 algorithms, and even changes in which algorithms are mandatory to 61 implement. 63 3. Change should be Anticipated 65 While CBC single mode DES is used in the current standard, it is 66 rather old and it is anticipated that the community should expect to 67 see an evolution to AES or some more modern algorithm in the future. 69 HMAC MD5 and HMAC SHA-1, as used in the SNMPv3 authentication 70 protocols, are considered to be the state of the art at the current 71 time, 73 4. Security Considerations 75 This document is about security, specifically that of the 76 cryptographic algorithms used by SNMPv3. It notes the status and 77 anticipated development of these algorithms, but is not believed to 78 change the security of the SNMPv3 protocol. 80 5. Acknowledgments 82 Bert Wijnen, Marcus Leech, and Jeff Schiller were instrumental in the 83 development of this document. 85 6. References 87 [RFC1157] 88 Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, 89 M.L. Schoffstall, C. Davin. May-01-1990. 91 [RFC1901] 92 Introduction to Community-based SNMPv2. J. Case, K. McCloghrie, M. 93 Rose, S. Waldbusser. 95 [RFC2316] 96 Report of the IAB Security Architecture Workshop. S. Bellovin. 98 INTERNET-DRAFT AS for SNMPv3 Cryptographic Algorithms 2002.02.22 100 April 1998. 102 [DESCRACK] 103 "Cracking DES: Secrets of Encryption Research, Wiretap Politics, 104 and Chip Design". J. Gilmore. O'Reilly and Associates. 1998. 106 7. Authors' Addresses 108 Steven M Bellovin 109 AT&T Shannon Laboratory, Room E-215 110 180 Park Ave. Bldg. 103 111 Florham Park, NJ US-07932-0000 112 +1 973 360 8656 113 +1 973 360 8077 fax 114 smb@research.att.com 116 Randy Bush 117 5147 Crystal Springs 118 Bainbridge Island, WA US-98110 119 +1 206 780 0431 120 randy@psg.com 122 8. Full Copyright Statement 124 Copyright (C) The Internet Society (2002). All Rights Reserved. 126 This document and translations of it may be copied and furnished to 127 others, and derivative works that comment on or otherwise explain it 128 or assist in its implementation may be prepared, copied, published and 129 distributed, in whole or in part, without restriction of any kind, 130 provided that the above copyright notice and this paragraph are 131 included on all such copies and derivative works. However, this 132 document itself may not be modified in any way, such as by removing 133 the copyright notice or references to the Internet Society or other 134 Internet organizations, except as needed for the purpose of developing 135 Internet standards in which case the procedures for copyrights defined 136 in the Internet Standards process must be followed, or as required to 137 translate it into languages other than English. 139 The limited permissions granted above are perpetual and will not be 140 revoked by the Internet Society or its successors or assigns. 142 This document and the information contained herein is provided on an 143 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 144 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 145 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 146 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 147 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.