| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Colleagues,
Since 802.21 is discussing access control and security related issues with en eye towards future work, I'd like to point out that a number of the facilities in the MIH protocol have analogs in the SNMP model. Here is my review of the concepts of SNMPv3 just as a way of stimulating the discussion and thoughts. I've cc'd one of the authors so he can correct where I might have strayed ;^)
It seems likely that SNMPv3 security and its USM are going to be raised as possible models, at least to learn from. Since SNMP also has the hop by hop proxy concept, there are additional similarities to some of our issues. This raises some security requirements.
The fact that .21 didn't take on the ability to update the MIIS database with reports (ala TRAPs) from the MIHF 'agents' (to use more SNMP parlance) has been something of a criticism of MIIS definition. There are security and access control implications to that concept as well if .21 ever addresses this.
For SNMPv3 the basic architecture is in RFC 3411, and security is mostly defined in RFC 3414 (and 3415 for access control). SNMPv3 defines the interfaces/services and the process by which a PDU flows through the four man components (dispatch, message processing, security and access control.) For security it defines the User Security Model (USM), based around a username ID. USM provides authentication and confidentiality services and is designed to secure authentication, message integrity, replay protection and confidentiality. USM is not intended to secure against DoS or traffic analysis threats.The username (actually two parts, there is a security name string too) is similar to the .21 MIH user. In SNMPv3, the 'engine" knows about users and their attributes so it can do access control and authentication per user.
The reasoning behind ignoring DoS is that many DoS attacks are indistinguishable from normal network failures . Also, a DoS attack is likely to disrupt all types of exchanges and is a matter for an overall or gateway security facility, not one embedded in a network management protocol. Wrt traffic analysis, the argument went that the traffic patterns are going to be predictable. There's only one or a few SNMP management boxes (c.f. MIH command or information servers) so there is no significant advantage to protecting against observing these traffic patterns.
SNMPv3 has two cryptographic functions defined for USM: authentication+integrity protection, and encryption. To support these functions, an SNMP engine has two keys, an encryption (privacy) key and an authentication key. Separate values of these two keys are maintained for local and remote users. These values are user attributes stored for each relevant user. Two authentication protocols are specified, and a CBC method for encryption. Unfortunately, most of the crypto in the spec is now deprecated by the security community as algorithms have been broken. The structure of the standard allows for new algorithms to be plugged in easily. The encryption header is prepended to the regular SNMP PDU, riding on top of UDP. The values of each key are not accessible via SNMP.
There is a message timeliness concept, which is enforced by assigning the receiver of the commands and notifications to have the authoritative clock. In the proxy and traps, the sender's clock is authoritative. The sender and receiver include their estimates of the other's clock values in some of the messages. The authoritative clock messages allow the receiver to sync.The clock is the number of seconds since the last reboot. This is designed to provide replay protection.
The separate security subsystem is responsible for adding the encryption header. The header includes the authoritative node's 'engine ID' (i.e. not always the sender's) along with a value counting the number of reboots the engine has gone through, and the time since the last reboot , the user ID, the engine ID and other fields. Key management for encryption is such that although the same username may use multiple SNMP engines, each key is unique to the user and the engine+security subsystem instance.
Best Regards,
Michael