Subject: RE: [midcom] key distribution

From: "Harrington, David" <[email-masked]>
Date: Tue, 10 Dec 2002 18:29:57 -0500

Hi,

Let me make sure everybody understands what is available for key management in SNMPv3, and where problems might arise. 

SNMPv3 provides standardized mechanisms for a user to change their own keys, and standardized mechanisms for administartors to change large numbers of users' keys, by making mibs available through which one can do these things. Obviously, with large numbers of keys, using a program to automate the process would be desirable. 

SNMPv3 does not provide a standardized mechanism for creating the initial keys for a "root" user. Once a root user has been established, all subsequent key updates and key distribution can be done using SNMP applications. RFC2786 defines a Diffie-Hellman mechanism for establishing "root" user keys. It is not part of the SNMPv3 standard. It is part of the DOCSIS standard and has been used successfully in the cable modem industry, according to the reports I've received as WG co-chair. Since RFC2786 is not part of the standard, I do not consider that part of this evaluation.

As an alternative, implementors are free to use other key distribution mechanisms, such as Kerberos or ASCII scripts, and the underlying instrumentation in the SNMP-agent-hosting-device can automatically add support for various users to the SNMP MIBs that maintain the lists of users and their keys. This process can be automated, but it is not part of the SNMPv3 standard.

To simplify key distribution, many vendors are authenticating the "applications" that send messages rather than the users using the applications. Many applications require a user to login to the application, possibly with a RADIUS tie-in, and then the application (say, HPOV's Node Manager) authenticates itself to the managed entity and performs SNMP transactions for the user. The USM model does not place any requirements on the granularity of the things called "users"; they do not need to be humans.

The MIDCOM requirements do not seem to require that the authentication be directly manipulated in real-time by a human. It appears to me that the MIDCOM agent is an application that can be triggered by events other than user login, such as getting a communication from a SIP proxy. In this case, I do not think the authentication between the agent and middlebox is authenticating the human user, but rather the agent (application) identity and the middlebox identity. I see these as being likely to use preconfigured shared secrets.

Eliot's point about SNMPv3 security being orthogonal to RADIUS security is absolutely on the money. RADIUS largely follows the challenge and response model of user authentication. Because SNMP has no concept of session, authentication is done on every message. That means there is no login screen with human real-time challenge and response (we'd certainly very quickly tire of logging in every time we send a message). In the standard SNMPv3 model, the agent and middlebox will need to have pre-configured shared secrets for every security principal (human user or application) that sends a message that needs to be authenticated. 

SNMPv3 is designed to be extensible, to be able to use different security models besides the standard USM security model. Any such extensions are not included in this evaluation. Adding another security model that uses shared keys would not be terribly difficult to do. Adding a security model that depends on third-party authentication could be done with more work.

***BUT***, adding a security model that depends on third party authentication, using a challenge and response algorithm will not work easily in the session-less environment of SNMPv3. I have had a number of discussions with SNMP experts about adding RADIUS support to SNMPv3, and there are major difficulties in doing so.

If pre-configuration and updates of shared keys is acceptable to the MIDCOM design, then out-of-band key distribution should be fine with SNMPv3.

If compatibility with human real-time challenge-and-response login is important to the MIDCOM design, then Diameter is a WAY WAY better choice than SNMPv3.

dbh

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Tuesday, December 10, 2002 5:12 PM
> To: Harrington, David
> Cc: Eliot Lear; [email-masked]
> Subject: Re: [midcom] key distribution
> 
> 
> Hi David,
> 
> I believe that at least some rudimentary key management is necessary 
> for MIDCOM.  I agree that key management is not needed 
> generically for 
> SNMP, but if used as a MIDCOM protocol I think it becomes a 
> requirement.  I suspect this wasn't written down because most folks 
> were envisioning using one or more other protocols where some type of 
> key management is implied with the security mechanisms suggested for 
> those protocols.
> 
> thanks,
> -rohan
> 
> 
> On Tuesday, December 10, 2002, at 12:33 PM, Harrington, David wrote:
> > Hi Eliot,
> >
> > I certainly concur that distributed integrated key 
> distribution would 
> > be a nice thing for SNMPv3. Some proposals to use 
> Diffie-Hellman key 
> > distribution for SNMPv3 have been published and 
> implemented, but I do 
> > not consider them part of this evaluation. Some proposals to use 
> > Kerberos key distribution for SNMPv3 have been published and 
> > implemented, but I do not consider them part of this evaluation. I 
> > have had discussions about developing a security model for 
> SNMPv3 that 
> > uses third-party authentication and authorization, but that also is 
> > not part of this evaluation.
> >
> > I searched RFCs 3303 and 3304 and the semantics draft and found no 
> > discussion of key distribution as a requirement. While key 
> > distribution is not part of this evaluation, I think it is a valid 
> > concern. Melinda will need to determine whether discussion in this 
> > forum is appropriate, or merely a distracting rathole.
> >
> > When it comes to security and network management, I paid a 
> great deal 
> > of attention to the Security Area's meeting in Salt Lake City where 
> > they discussed the Security Requirements for Network Management 
> > protocols. In that meeting, they identified a number of 
> requirements - 
> > message authentication, message encryption, message 
> > integrity-checking, data access-control (there might have been a 
> > fifth; I haven't found the minutes of that meeting) - and 
> two elements 
> > that they considered were explicitly NOT requirements because they 
> > could be handled outside the protocol - data privacy 
> policies and key 
> > distribution. In fact, they found that SNMPv3 met all the 
> identified 
> > requirements, and there was discussion during that meeting, 
> involving 
> > Jeff Schiller as a matter of fact, about the desirability of being 
> > able to distribute the keys using ASCII configuration scripts.
> >
> > So I question, based on this guidance from the Security 
> Area, whether 
> > it needs to be integrated into the protocol. Any key distribution 
> > mechanism, Kerberos or ASCII scripts or Expect or XML, 
> should be able 
> > to be used to distribute keys. Key distribution is not 
> integrated into 
> > SNMPv3, except through the use of SNMPv3, by design.
> >
> > You mentioned that the SNMPv3 security model is novel. 
> That's probably 
> > true; it is designed to meet certain requirements that most 
> protocols 
> > do not need to meet. Most notably, the security was designed to 
> > operate standard-alone, in possibly broken networks, so 
> security was 
> > assured even when external authentication/authorization 
> servers could 
> > not be reached.
> >
> > dbh
> >
> >
> >
> >> -----Original Message-----
> >> From: Eliot Lear [mailto:[email-masked]]
> >> Sent: Tuesday, December 10, 2002 2:06 PM
> >> To: Harrington, David
> >> Cc: [email-masked]
> >> Subject: Re: [midcom] Protocol decision reminder
> >>
> >>
> >> Harrington, David wrote:
> >>> Hi Eliot,
> >>>
> >>> Is this in response to something I said?
> >>
> >> Generic comment about SNMP.  Melinda asked for comments.  I'm
> >> not sure
> >> SNMP meets MIDCOM requirements in their entirety.  Is it
> >> close enough?
> >> That's an interesting question...
> >>
> >> Eliot
> >>
> >>
> > _______________________________________________
> > midcom mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/midcom
> 
> 
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Eliot Lear <[email-masked]>
Date: Sat, 14 Dec 2002 13:19:39 -0800

Dave,

thanks for your answer regarding key management, but are you aware of a 
single implementation that actually does key management that includes 
both SNMP and other mechanisms?  I perceive a running code deficit 
precisely because of the difficulties you mentioned.

Eliot