idnits 2.17.1 draft-hornstein-snmpv3-ksm-02.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: ---------------------------------------------------------------------------- ** 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 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 131: '...ld. Implementations MUST include this...' 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 (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Ken Hornstein 3 NRL 4 March 1, 2001 Wes Hardaker 5 Expires: September 1, 2001 UC Davis 7 A Kerberos Security Model for SNMPv3 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Distribution of this memo is unlimited. It is filed as , and expires on September 1, 2001. 32 Please send comments to the authors. 34 Abstract 36 This document describes a proposed Kerberos Security Model (KSM) for 37 SNMP version 3 for use in the SNMP architecture [RFC2271]. It 38 defines the Elements of Procedure for providing SNMP message level 39 security with Kerberos [RFC1510]. 41 Introduction and Rationale 43 Kerberos [RFC1510] is a security system utilizing symmetric key cryp- 44 tography. In Kerberos, all keys are stored on a central Key Distri- 45 bution Center (KDC) and communication is required with the KDC as 46 part of the authentication process. 48 RFC DRAFT March 1, 2001 50 The tradeoffs between centralized and non-centralized services are 51 well known. One of the design goals of SNMP is to rely on as few 52 network services as possible, because these services may very well be 53 unavailable at the very time you wish to use network management to 54 repair the network. As a result, there has not been any significant 55 work done in exploring centralized authentication systems with SNMP. 57 However, the authors of this draft feel that centralized authentica- 58 tion systems still have their place within the SNMP framework. In 59 many environments there are multiple classes of users. Some users 60 will only have the ability to monitor the network, where some 61 (presumably smaller) group of users will have the ability to perform 62 administrative tasks. 64 It is our contention that in many cases, only the users that do 65 administration will need authentication when network services are 66 unavailable. For the larger class of users that only do monitoring, 67 centralized authentication would be perfectly appropriate. Note that 68 we recognize that this user service model may not be appropriate for 69 all environments. 71 Goals of this Security Model 73 As specified in the SNMP Architecture RFC [RFC2271], there are 74 threats that a security model must protect against. These include: 76 Modification of Information 77 The modification threat is the danger that some unauthorized SNMP 78 entity may alter in-transit SNMP messages generated on behalf of 79 an authorized principal in such a way as to effect unauthorized 80 management operations, including falsifying the value of an 81 object. 83 Masquerade 84 The masquerade threat is the danger that management operations not 85 authorized for some principal may be attempted by assuming the 86 identity of another principal that has the appropriate authoriza- 87 tions. 89 Message Stream Modification 90 The SNMP protocol is typically based upon a connectionless tran- 91 sport service which may operate over any subnetwork service. The 92 re-ordering, delay or replay of messages can and does occur 93 through the natural operation of many such subnetwork services. 94 The message stream modification threat is the danger that messages 95 may be maliciously re-ordered, delayed or replayed to an extent 96 which is greater than can occur through the natural operation of a 97 subnetwork service, in order to effect unauthorized management 99 RFC DRAFT March 1, 2001 101 operations. 103 Disclosure 104 The disclosure threat is the danger of eavesdropping on the 105 exchanges between SNMP engines. Protecting against this threat 106 may be required as a matter of local policy. 108 The Kerberos Security Model provides protection against all of these 109 threats, as these features are already built into the Kerberos proto- 110 col [RFC1510]. 112 This Security Model provides no protection against Denial of Service 113 or Traffic Analysis attacks. 115 SNMP Messages Using this Security Model 117 The syntax of an SNMP message using this Security Model adheres to 118 the message format defined in the version-specific Message Processing 119 Model document (for example [RFC2272]). 121 The field msgSecurityParameters in SNMPv3 messages has a data type of 122 OCTET STRING. Its value is the BER serialization of a KRB_AP_REQ 123 messsage for Request messages and the BER serialization of a 124 KRB_AP_REP message for Response messages. The formats of the 125 KRB_AP_REQ and KRB_AP_REP messages are defined by the Kerberos 5 RFC 126 [RFC1510]. 128 The application specific checksum (referred to in section 3.2.2 of 129 [RFC1510]) which is contained in the authenticator of the KRB_AP_REQ 130 shall be computed using the BER serialization of the fields prior to 131 the msgSecurityParameters field. Implementations MUST include this 132 checksum for all Request messages. 134 Generating an Outgoing SNMP Message 136 This Section describes the procedure followed by an SNMP engine when- 137 ever it generates a message containing a management operation (like a 138 request, a response, a notification, or a report) on behalf of a 139 user, with a particular securityLevel. 141 1) a) If any securityStateReference is passed (Response message), 142 then information concerning the state of the Kerberos protocol 143 is extracted from the cachedSecurityData. This typically 144 includes a session key and client principal name. This data 145 is used to construct an appropriate KRB_AP_REP message. 147 Otherwise, 149 RFC DRAFT March 1, 2001 151 b) the current Kerberos credentials available to the client, the 152 Kerberos service name of "host", and the Kerberos localization 153 information (which consist of a DNS domain name and optionally 154 an IP address when using the IP suite) of the destination SNMP 155 engine are used to construct an KRB_AP_REQ message. This may 156 involve contacting a Kerberos KDC if credentials for this ser- 157 vice have not already been cached. 159 2) The resulting BER serialized KRB_AP_REQ or KRB_AP_REP is placed 160 into the securityParameters field. 162 3) a) If the securityLevel specificies that the message is to be 163 protected from disclosure, then the SNMP payload (the 164 scopedPDU) is used as the payload of a KRB_PRIV message. 166 Otherwise, 168 b) If the securityLevel just specifies that the message is to be 169 authenticated, the SNMP payload (the scopedPDU) is used as the 170 payload of a KRB_SAFE message. 172 3) The resulting BER serialized KRB_PRIV or KRB_SAFE message is 173 placed as the msgData field. 175 4) The completed message with its length is returned to the calling 176 module with the statusInformation set to success. 178 Processing an Incoming SNMP Message 180 This section describes the procedure followed by an SNMP engine when- 181 ever it receives a message containing a management operation on 182 behalf of a user, with a particular securityLevel. 184 1) If the received securityParameters is not the serialization of a 185 KRB_AP_REQ or KRB_AP_REP message, then the snmpInASNParseErrs 186 counter [RFC1907] is incremented, and an error indication (par- 187 seError) is returned to the calling module. 189 2) The KRB_AP_REQ/KRB_AP_REP (depending if this is a request or a 190 response) is verified via the Kerberos protocol, and the client 191 identity is extracted from the message. The client principal is 192 converted into an ASCII string via the rules specified in RFC 193 1510 [RFC1510] and this is used as the securityName for this PDU. 195 3) a) If the securityLevel specified that this message was to 196 be protected from disclosure, the msgData field will be ver- 197 fied by Kerberos. If this field is not the BER serialization 198 of a KRB_PRIV message, then the snmpInASNParseErrs counter 200 RFC DRAFT March 1, 2001 202 [RFC1907] is incremented, and an error indication (parseError) 203 is returned to the calling module. If the Kerberos verifica- 204 tion fails, an error indication is returned. 206 Otherwise, 208 b) The msgData field will be verified by Kerberos. If this field 209 is not the BER serialization of a KRB_SAFE message, then the 210 snmpInASNParseErrs counter [RFC1907] is incremented, and an 211 error indication (parseError) is returned to the calling 212 module. If Kerberos verification fails, an error indication 213 is returned. 215 4) If this message is a request, the session key and other Kerberos 216 information needed for a response will be placed into the securi- 217 tyStateReference field. 219 5) The statusInformation is set to success and a return is made to 220 the calling module. 222 Security considerations 224 The security of this Security Model depends entirely on the security 225 of Kerberos and the basic assumptions that it is built upon. Thus, 226 the security considerations of the KSM are the same as the Kerberos 227 protocol itself. 229 Authors' Note 231 The authors of this Internet-Draft acknowledge that the outline and a 232 large amount of the text of this draft comes from the USM RFC 233 [RFC2274]. 235 Expiration 237 This Internet-Draft expires on September 1, 2001. 239 References 241 [RFC1510] 242 The Kerberos Network Authentication System; Kohl, Newman; Sep- 243 tember 1993. 245 [RFC1907] 246 Management Information Base for Version 2 of the Simple Network 247 Management Protocol (SNMPv2); Case, McCloghrie, Rose, Wald- 248 busser; January 1996. 250 RFC DRAFT March 1, 2001 252 [RFC2271] 253 An Architecture for Describing SNMP Management Frameworks; Har- 254 rington, Presuhn, Wijnen; January 1998. 256 [RFC2272] 257 Message Processing and Dispatching for the Simple Network 258 Management Protocol (SNMP); Case, Harrington, Presuhn, Wijnen; 259 January 1998. 261 [RFC2274] 262 User-based Security Model (USM) for version 3 of the Simple Net- 263 work Management Protocol (SNMPv3); Blumenthal, Wijnen; January 264 1998. 266 Authors' Addresses 268 Ken Hornstein 269 US Naval Research Laboratory 270 Bldg A-49, Room 2 271 4555 Overlook Avenue 272 Washington DC 20375 USA 274 Phone: +1 (202) 404-4765 275 EMail: kenh@cmf.nrl.navy.mil 277 Wes Hardkar 278 IT-DCAS 279 University of California, Davis 280 Davis CA 95616 USA 282 Phone: +1 (530) 754-7571 283 EMail: wjhardaker@ucdavis.edu