snmp v 3 one more time Network MgmtSec

snmp v 3 (one more time) Network Mgmt/Sec. Jim Binkley 1

aka u is three really the charm? Jim Binkley 2

Outline u intro u architecture/structure - u more protocol u user-based security – authentication/encryption/key management u view-based Jim Binkley access control (brief) 3

bibliography, RFC-wise (jan/98) u 2271 - Architecture u 2272 - Message Processing/Dispatch u 2273 - v 3 applications (functional parts) u 2274 - User-Based Security Model u 2275 - View-Based Access Control Model Jim Binkley 4

so what is it? u v 2 + – protocol security, i. e. , authentication/confidentiality/key management » this is the User-Based Security model » note: confidentiality is called privacy – an enhanced access-control model » based on MIB views » and groups » this is the View-Based Access Control model Jim Binkley 5

protocol overview u roughly global hdr (v 3 wrapper, (v 2/v 1 PDU)) snmp v 3 part sec. model scoped pdu snmp pdu hdr (v 2 bits) crypto-fied part pdu part may be authenticated OR auth/encrypted Jim Binkley 6

architectural elements/dictionary u snmp. Engine. Id - a string that uniquely defines a manager or agent or combo, note == context. Engine. Id, may have many contexts u context. Engine. Id - identity with a context u context. Name - parameter to access control subsystem, set of MIB objects, string – objects can be lumped into named sets with different rights associated (readonly, writeable) Jim Binkley 7

we have new terms u scoped. PDU - PDU with context. Engine. ID, context. Name u snmp. Security. Model - which sec. model – v 1, v 2 c, USM are possible u snmp. Security. Level – no. Authno. Priv, auth. No. Priv, auth. Priv u principal - for whom do we do all this crud – people ultimately but processes in real life u security. Name Jim Binkley - string representing principal 8

snmp. Engine. Id something like: u 12 bytes long acc. to Agent. ID, rfc 1910 or u (4 bytes of private enterprise number) + more bytes with byte 5 indicating: – IPv 4 address (thus 6, 7, 8, 9) (byte 5 = 1) – IPv 6 address (add 16) – MAC – text (max is 27) Jim Binkley 9

generalized abstract architecture applications (snmp of course) - forms pdus, get, response, etc snmp engine (id is snmp. Engine. Id) - does subsystem processing including security, access control Jim Binkley 10

applications include u command generator, *does get/getnext/getbulk/set and processes response received u command responder, recvs get, etc. , and sends response u notification recv/originator (traps/informs) Jim Binkley 11

snmp engine parts u dispatcher - i/f to apps/network/and other snmp engine parts u message processing- tie the v 3 message together from sub-systems including: – and might do v 1/v 2/v 3 messages. . . u security subsystem - user-based sec. model u access control - view-based model Jim Binkley 12

access-control subsystem primtitive (e. g. , ) u is. Access. Allowed() parameters include: – security. Model INPUT (e. g. , USM) – security. Name INPUT (principal) – security. Level IN (e. g. , auth only) – view. Type IN (read/write/notify view) – context. Name IN (contains variable. Name) – variable. Name IN (OID. . . ) – status. Information returned - OK or boo hiss Jim Binkley 13

application MIBs for v 3 u SNMP-TARGET-MIB defines objects for defining who to send notifications and/or proxy messages to u SNMP-NOTIFICATION-MIB defines objects for remote config of notifications u SNMP-PROXY-MIB contains info for remote config of proxy Jim Binkley 14

SNMP-TARGET-MIB u snmp. Target. Objects contains: – snmp. Target. Spin. Lock(1) – snmp. Target. Addr. Table(2) » use UDP with IP addr Y, timeout T, retry R etc. – snmp. Target. Params. Table(3) » v 1/v 2/v 3, security. Model, security. Name, security. Level – and more. . . Jim Binkley 15

NOTIFICATION MIB u three tables including: – snmp. Notify. Table - select who to notify from previous snmp. Target. Addr. Table – snmp. Notify. Filter. Profile. Table - associate filters with a particular target – snmp. Notifyfilter. Table - define filters Jim Binkley 16

protocol overview u roughly global hdr (v 3 wrapper, (v 2/v 1 PDU)) snmp v 3 part sec. model scoped pdu snmp pdu hdr (v 2 bits) crypto-fied part pdu part may be authenticated OR auth/encrypted Jim Binkley 17

header contains 5 fields (still TLVs): u msg. Version (3 for v 3) - INTEGER u msg. ID (request ID) - INTEGER u msg. Max. Size - max segment size e. g. , response u msg. Flags - flag bits, – reportable. Flag (bit 1) - if set, report may be sent, if not set, report may NOT be set (used if message encrypted but not decodable) – priv. Flag = 1, was encrypted – auth. Flag = 1, was authenticated Jim Binkley 18

cont. u msg. Security. Model - 1 for v 1, 2 for v 2 c, 3 for USM Jim Binkley 19

scoped pdu has 3 parts u context ID (engine ID) and u context name u used in access control Jim Binkley 20

USM header part u msg. Authoritative. Engine. Id - likely the agent’s engine Id u msg. Authoritative. Engine. Boots - # of reboots u msg. Authoritative. Engine. Time - # of secs since reboot u msg. User. Name - principal name for msg u msg. Authentication. Parameters - hash u msg. Privacy. Parameters - IV Jim Binkley 21

USM - authoritative engine u means receiver of get/getnext/getbulk/set/inform u OR sender of trap/response u time in message consists of 2 -tuple – (boot count N, time since boot) u based on clock in authoritative engine – non-authoritative msg sender must estimate time in authoritative engine Jim Binkley 22

initialization protocol exists u 2 -step discovery mechanism exists to allow one to obtain info about other entities (agents) u nonauth. engine sends request with no security and user name “initial”, recvs snmp. Engine. Id back u if authentication used, sends authenticated request to get back boots and time values Jim Binkley 23

USM functionality (security model) u crypto u anti-replay and time u usm. User group u key management – password to hash key mechanism – key localization – key update Jim Binkley 24

USM security overview u denial of service attacks - NO help here – probably such an attack is more fundamental than just an attack on SNMP u traffic analysis - NO u note that authentication is non-trivial – encryption if DES based not so strong – may need better algorithm or folding of SNMP across WAN inside IPSEC anti-replay Jimu Binkley features exist (time) 25

anti-replay could fred record and play back the msg stream? evil fred authenticated msgs mgr Jim Binkley agent 26

time-replay u (boot count, ticks since boot) in message u allows recv to judge if message is “too old”, can send not. In. Time. Window error u non-auth. engine must keep track of auth. engines time u auth. engine must keep time window and track timeliness of messages (so does non-auth engine) u roughly boot count must match and msg must be within 150 seconds of stored time Jim Binkley 27

crypto u authentication algorithms – HMAC-MD 5 -96 » 128 bit auth. Key/output truncated to 96 bit hash – HMAC-SHA-96 » 160 bit key/output again truncated to 96 bits u encryption – DES-CBC (still a revolutionary act) » 56 bit in 8 octets, least significant bit ignored Jim Binkley 28

usm. User group u information about local and remote principals u spinlock plus usm. User. Table which includes: – usm. User. Engine. ID - authoritative engine ID (local/remote) – usm. User. Name - principal name, e. g. , “bob” – usm. User. Security. Name - security. Name (same as above) – usm. User. Clone. From - pointer to another conceptual row - used to point to keys and clone keys – usm. User. Auth. Protocol - none, hmac-md 5 (def), h-sha Jim Binkley 29

cont. u u u usm. User. Auth. Key. Change - byte string with key. Change syntax. causes key. Change hash function to occur in terms of key update usm. User. Own. Auth. Key. Change - user can change only own key usm. User. Priv. Protocol - none (def), DES usm. User. Priv. Key. Change - drive key change usm. User. Own. Priv. Key. Change usm. User. Public - not clear Jim Binkley 30

processing u to send – encrypt 1 st then authenticate – before authentication, store time values u to recv – note security. Engine. ID/security. Name used for lookup in usm. User. Table – perform authentication check – then perform decrypt if needed Jim Binkley 31

key management u it is assumed that there are separate keys for authentication and encryption (by definition) u each principal has a pair of keys u keys cannot be obtained via SNMP (gets) – duh. . . u key localization and password to key allow one user to access many agents with Jim Binkley one set of keys 32

password to key u human-readable password mapped by function into desired crypto keys u RFC 2274 defines algorithm u passwords should not be poor of course u password is duplicated to produce string of 2 ** 20 bytes (slow down brute-force attack) u if MD 5 used, take md 5 hash to form digest Jim Binkley 33

key localization u keys are localized by taking hashed user key and hashing it again with remote Engine. ID value u f (user key(hashed), Engine. ID) -> digest/key u this is called localized key u upshot: use localized key - if attacker captures on wire, && breaks it, can only Jim Binkley attack one agent 34

key update u initial keys must “somehow” be installed out of band – assume manually u post initial installation, key change or update process can be initiated by user u done by using hash function + XOR u f(key. Old, random bits, etc). , where the keys are not sent, but random bits are transmitted u hash function is one way, if new key learned, old key not derivable Jim Binkley 35

view-based access control model u group – has groupname – list of principals (security. Name) + security. Model with same access rights – security. Model e. g. , USM or SNMPv 1 community u context – basically a MIB view (defined by tree and filter) – has name Jim Binkley 36

and the point. . . u we might wish to restrict access on engine Y to – user Z can read anything but can’t write anything – user X can write but has to have a auth key with USM » or stronger. . . encrypted too – notify privileges must be considered as well (e. g. , traps must be authenticated) Jim Binkley 37

scoped pdu in v 3 headers u context. Engine. Id - which application gets it u context. Name - the MIB view via a simple string name u and yes, the actual SNMP PDU (presumably a V 2 PDU) Jim Binkley 38

VBACM elements u u u msg. User. Name/msg. Security. Model mapped into group. Name context. Engine. ID - who carries it out context. Name - what MIB objects msg. Authentication. Parameters - checked out by USM before it gets to VACM access control based on group. Name, context. Name, security Model, security. Level (from msg. Flags) MIB view determined by vacm. Access. Table and PDU operation type (read/write/notify) Jim Binkley 39