RE: RE : RE : DHCP options drafts

Hi Joel,

Comments inline. 

> -----Original Message-----
> From: Joel Tran [mailto:[email protected]] 
> Sent: Monday, April 05, 2004 3:19 PM
> To: Harrington, David; [email protected]
> Subject: RE : RE : [midcom] DHCP options drafts
> 
> Comments inline.
> 
> > Since the communications between a midcom agent and the
> > middlebox is done via SNMPv3, to provide mutual
> > authentication, the discovery needs to be done using SNMPv3.
> 
> True, preferably, the discovery should by done using SNMPv3. 
> However, I
> can't figure out one thing: How we can ONLY identify SNMPv3 
> agent performing
> Midcom services in an effective way? With the use of DHCP, we 
> can pin-point
> directly the Midcom device in a network.

Using SNMPv3's initial discovery mechanism, one engine can discover the
other engine's engineID and time sync parameters. If the application
(SNMP manager) knows the pre-shared keys of the SNMP agent on the
middlebox, the application can look to see if the MIDCIM MIB module is
supported by doing a GET of one or more of the OIDs used in the MIDCOM
MIB module. That type of discovery is standard operating procedure for
most SNMP applications.

That type of discovery would be appropriate for discovering MIDCOM
agents and middleboxes. If an application searching for middleboxes
doesn't have the shared keys for the middlebox, then it probably
shouldn't be given access to determine what specific types of
functionality the other SNMP engine supports.

This argues for having the application (MIDCOM agent) record the address
of the middlebox whose SNMPv3 keys are being set into its database.

> 
> > DHCP is good for dynamically assigning addresses, but SNMPv3
> > has specific requirements about the identification of managed
> > nodes, and addresses have proven inadequate for
> > identification purposes, largely as the result of
> > technologies such as DHCP and NAT.
> 
> DHCP serves as assigning dynamically addresses and 
> configuration parameter.
> In our case, Midcom agent needs to know the addresses of 
> Midcom middlebox.
> DHCP provides this means. For identification/authentication 
> is out of scope
> of DHCP. The Midcom agent will thus have to provide 
> authentication to the
> Midcom middlebox.

I think there is a question of the order of events. If both sides need
to know the shared keys, wouldn't an operator be likely to be able to
tell the midcom agent what the address of the middlebox is at the same
time? 

What is the usage scenario that requires DHCP to tell the midcom agent
the address of the middlebox, if the shared keys have already been set
into both devices? 

Understand that I am not objecting to the use of DHCP. I am trying to
understand the scenario in which it is actually necessary, given that
SNMPv3 currently requires key distribution for mutual authentication
before secure communications can be established. SNMPv3 was explicitly
designed to protect its information from disclosure to unauthenticated
entities. During SNMpv3 design discussions, there was a significant
segemnt of the market (part of the US govt) that argued an SNMPv3 engine
shouldn't reply to an unauthenticed entity because that would reveal
that an SNMP engine exists at a given address. On top of the strong
authentication, seeing into the MIB to see what functionality is
supported is tightly controlled by design, using the VACM access control
model. 

Given that MIDCOM is designed to manipulate security-related features
such as firewalls and NATs, it is fairly imperative that a strong SNMPv3
security model is maintained. A hacker would need to work to get through
the SNMPv3 authentication mechanisms to talk to the box, and then past
the data access controls (authorizations) to determine that a box
supports the MIDCOM MIB module. I am not convinced that using DHCP to
advertise "the entity at this address is a middlebox, with SNMP support
of the MIDCOM MIB module" is a very secure thing to do, and that it
doesn't defeat some of the SNMPv3 security philosophy to a degree. 


It helps the hacker to discover which services are running on which
boxes, which is why port scans are considered a general security threat.
What mechanisms are in place to ensure that DHCP doesn't disclose
information about entities that shouldn't be disclosed? What happens if
the DHCP server is compromised?

OTOH, SNMpv3 was also designed explicitly to not use obscurity as a
security mechanism. Even if you tell a hacker that a device is a
middlebox manageable using the MIDCOM MIB module, the SNMPv3 security
should prevent them gaining unauthorized access. 
 
> 
> > It is also possible to
> > have multiple SNMPv3 agents at the same address (e.g. to
> > manage different types of functionality present on the same
> > box),
> 
> Quick question, in this case, are all the SNMP agents 
> listening to the port
> or they have individual port?

Multiple agents MAY work together, with one agent listening on a given
port, and then the "dispatcher" of the SNMP listener can forward the
requests directly to the appropriate registered engine, possibly (but
not necessarily) through a different port. There are multiple SNMP-legal
ways to support multiple engines at the same address, including the SNMP
proxy mechanisms defined in RFC3413(?).

> 
> > That's why SNMPv3 uses engineIDs for identification. SNMPv3
> > discovery entails a type of mutual discovery, during which
> > the SNMP engines share their SNMPv3 engineIDs, and clock sync
> > information. This permits SNMPv3 to communicate with
> > different engines at a given address, or to recognize when
> > one engine has multiple addresses. This discovered
> > information cannot be provided via DHCP.
> 
> > There is also the issue of key distribution. The initial
> > distribution of keys must be done outside SNMPv3, using a
> > secure protocol. This may accomplished using a key
> > distribution protocol, such as kerberos, or by kickstarting a
> > "root" or "admin" type of security relationship, and then
> > distributing additional keys using SNMPv3. DHCP is
> > inappropriate for key distribution.
> 
> > DHCP might be useful for saying "there is an SNMP engine
> > (which may be a midcom agent or a middlebox or some other
> > type of SNMP engine) at address a.b.c.d, but the information
> > DHCP provides alone will be inadequate for establishing
> > secure SNMPv3 communications or for establishing non-secure
> > SNMPv3 communications. It might be adequate for identifying
> > where there is an SNMP engine that could then be "discovered"
> > using SNMPv3 discovery. If DHCP provided the engineIDs for
> > the SNMP engines, as well as the addresses to use to reach
> > each SNMP engine, that could be a good thing.
> 
> As you mentioned, it will probably be interesting to provide 
> engineIDs to
> identify the good SNMPv3 agent in the document. Anybody have 
> some other
> comments on this?
> 
> 
> ...J
> 
David Harrington            
[email protected]
co-chair, IETF SNMPv3 WG, concluded