idnits 2.17.1 draft-hornstein-snmpv3-ksm-00.txt: 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** The abstract seems to contain references ([RFC1510], [RFC1907], [RFC2271], [RFC2272], [RFC2274]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 1907 (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 2271 (Obsoleted by RFC 2571) ** Obsolete normative reference: RFC 2272 (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2274 (Obsoleted by RFC 2574) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Ken Hornstein 2 NRL 3 June 25, 1999 Wes Hardaker 4 Expires: December 25, 1999 UC Davis 6 A Kerberos Security Model for SNMPv3 8 Status of this Memo 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 Distribution of this memo is unlimited. It is filed as , and expires on December 21, 1999. Please send 31 comments to the authors. 33 Abstract 35 This document describes a proposed Kerberos Security Model (KSM) for 36 SNMP version 3 for use in the SNMP architecture [RFC2271]. It 37 defines the Elements of Procedure for providing SNMP message level 38 security with Kerberos [RFC1510]. 40 Introduction and Rationale 42 Kerberos [RFC1510] is a security system utilizing symmetric key cryp- 43 tography. In Kerberos, all keys are stored on a central Key Distri- 44 bution Center (KDC) and communication is required with the KDC as 45 part of the authentication process. 47 RFC DRAFT June 25, 1999 49 The tradeoffs between centralized and non-centralized services are 50 well known. One of the design goals of SNMP is to rely on as few 51 network services as possible, because these services may very well be 52 unavailable at the very time you wish to use network management to 53 repair the network. As a result, there has not been any significant 54 work done in exploring centralized authentication systems with SNMP. 56 However, the authors of this draft feel that centralized authentica- 57 tion systems still have their place within the SNMP framework. In 58 many environments there are multiple classes of users. Some users 59 will only have the ability to monitor the network, where some 60 (presumably smaller) group of users will have the ability to perform 61 administrative tasks. 63 It is our contention that in many cases, only the users that do 64 administration will need authentication when network services are 65 unavailable. For the larger class of users that only do monitoring, 66 centralized authentication would be perfectly appropriate. Note that 67 we recognize that this user service model may not be appropriate for 68 all environments. 70 Goals of this Security Model 72 As specified in the SNMP Architecture RFC [RFC2271], there are 73 threats that a security model must protect against. These include: 75 Modification of Information 76 The modification threat is the danger that some unauthorized SNMP 77 entity may alter in-transit SNMP messages generated on behalf of 78 an authorized principal in such a way as to effect unauthorized 79 management operations, including falsifying the value of an 80 object. 82 Masquerade 83 The masquerade threat is the danger that management operations not 84 authorized for some principal may be attempted by assuming the 85 identity of another principal that has the appropriate authoriza- 86 tions. 88 Message Stream Modification 89 The SNMP protocol is typically based upon a connectionless tran- 90 sport service which may operate over any subnetwork service. The 91 re-ordering, delay or replay of messages can and does occur 92 through the natural operation of many such subnetwork services. 93 The message stream modification threat is the danger that messages 94 may be maliciously re-ordered, delayed or replayed to an extent 95 which is greater than can occur through the natural operation of a 96 subnetwork service, in order to effect unauthorized management 98 RFC DRAFT June 25, 1999 100 operations. 102 Disclosure 103 The disclosure threat is the danger of eavesdropping on the 104 exchanges between SNMP engines. Protecting against this threat 105 may be required as a matter of local policy. 107 The Kerberos Security Model provides protection against all of these 108 threats, as these features are already built into the Kerberos proto- 109 col [RFC1510]. 111 This Security Model provides no protection against Denial of Service 112 or Traffic Analysis attacks. 114 SNMP Messages Using this Security Model 116 The syntax of an SNMP message using this Security Model adheres to 117 the message format defined in the version-specific Message Processing 118 Model document (for example [RFC2272]). 120 The field msgSecurityParameters in SNMPv3 messages has a data type of 121 OCTET STRING. Its value is the BER serialization of a KRB_AP_REQ 122 messsage for Request messages and the BER serialization of a 123 KRB_AP_REP message for Response messages. The formats of the 124 KRB_AP_REQ and KRB_AP_REP messages are defined by the Kerberos 5 RFC 125 [RFC1510]. 127 Generating an Outgoing SNMP Message 129 This Section describes the procedure followed by an SNMP engine when- 130 ever it generates a message containing a management operation (like a 131 request, a response, a notification, or a report) on behalf of a 132 user, with a particular securityLevel. 134 1) a) If any securityStateReference is passed (Response message), 135 then information concerning the state of the Kerberos protocol 136 is extracted from the cachedSecurityData. This typically 137 includes a session key and client principal name. This data 138 is used to construct an appropriate KRB_AP_REP message. 140 Otherwise, 142 b) the current Kerberos credentials available to the client, the 143 Kerberos service name of "host", and the Kerberos localization 144 information (which consist of a DNS domain name and optionally 145 an IP address when using the IP suite) of the destination SNMP 146 engine are used to construct an KRB_AP_REQ message. This may 147 involve contacting a Kerberos KDC if credentials for this 149 RFC DRAFT June 25, 1999 151 service have not already been cached. 153 2) The resulting BER serialized KRB_AP_REQ or KRB_AP_REP is placed 154 into the securityParameters field. 156 3) a) If the securityLevel specificies that the message is to be 157 protected from disclosure, then the SNMP payload (the 158 scopedPDU) is used as the payload of a KRB_PRIV message. 160 Otherwise, 162 b) If the securityLevel just specifies that the message is to be 163 authenticated, the SNMP payload (the scopedPDU) is used as the 164 payload of a KRB_SAFE message. 166 3) The resulting BER serialized KRB_PRIV or KRB_SAFE message is 167 placed as the msgData field. 169 4) The completed message with its length is returned to the calling 170 module with the statusInformation set to success. 172 Processing an Incoming SNMP Message 174 This section describes the procedure followed by an SNMP engine when- 175 ever it receives a message containing a management operation on 176 behalf of a user, with a particular securityLevel. 178 1) If the received securityParameters is not the serialization of a 179 KRB_AP_REQ or KRB_AP_REP message, then the snmpInASNParseErrs 180 counter [RFC1907] is incremented, and an error indication (par- 181 seError) is returned to the calling module. 183 2) The KRB_AP_REQ/KRB_AP_REP (depending if this is a request or a 184 response) is verified via the Kerberos protocol, and the client 185 identity is extracted from the message. The client principal is 186 converted into an ASCII string via the rules specified in RFC 187 1510 [RFC1510] and this is used as the securityName for this PDU. 189 3) a) If the securityLevel specified that this message was to 190 be protected from disclosure, the msgData field will be ver- 191 fied by Kerberos. If this field is not the BER serialization 192 of a KRB_PRIV message, then the snmpInASNParseErrs counter 193 [RFC1907] is incremented, and an error indication (parseError) 194 is returned to the calling module. If the Kerberos verifica- 195 tion fails, an error indication is returned. 197 Otherwise, 199 RFC DRAFT June 25, 1999 201 b) The msgData field will be verified by Kerberos. If this field 202 is not the BER serialization of a KRB_SAFE message, then the 203 snmpInASNParseErrs counter [RFC1907] is incremented, and an 204 error indication (parseError) is returned to the calling 205 module. If Kerberos verification fails, an error indication 206 is returned. 208 4) If this message is a request, the session key and other Kerberos 209 information needed for a response will be placed into the securi- 210 tyStateReference field. 212 5) The statusInformation is set to success and a return is made to 213 the calling module. 215 Security considerations 217 The security of this Security Model depends entirely on the security 218 of Kerberos and the basic assumptions that it is built upon. Thus, 219 the security considerations of the KSM are the same as the Kerberos 220 protocol itself. 222 Authors' Note 224 The authors of this Internet-Draft acknowledge that the outline and a 225 large amount of the text of this draft comes from the USM RFC 226 [RFC2274]. 228 Expiration 230 This Internet-Draft expires on December 25, 1999. 232 References 234 [RFC1510] 235 The Kerberos Network Authentication System; Kohl, Newman; Sep- 236 tember 1993. 238 [RFC1907] 239 Management Information Base for Version 2 of the Simple Network 240 Management Protocol (SNMPv2); Case, McCloghrie, Rose, Wald- 241 busser; January 1996. 243 [RFC2271] 244 An Architecture for Describing SNMP Management Frameworks; Har- 245 rington, Presuhn, Wijnen; January 1998. 247 [RFC2272] 249 RFC DRAFT June 25, 1999 251 Message Processing and Dispatching for the Simple Network 252 Management Protocol (SNMP); Case, Harrington, Presuhn, Wijnen; 253 January 1998. 255 [RFC2274] 256 User-based Security Model (USM) for version 3 of the Simple Net- 257 work Management Protocol (SNMPv3); Blumenthal, Wijnen; January 258 1998. 260 Authors' Addresses 262 Ken Hornstein 263 US Naval Research Laboratory 264 Bldg A-49, Room 2 265 4555 Overlook Avenue 266 Washington DC 20375 USA 268 Phone: +1 (202) 404-4765 269 EMail: kenh@cmf.nrl.navy.mil 271 Wes Hardkar 272 IT-DCAS 273 University of California, Davis 274 Davis CA 95616 USA 276 Phone: +1 (530) 754-7571 277 EMail: wjhardaker@ucdavis.edu