Subject: [midcom] key distribution

From: "Harrington, David" <[email-masked]>
Date: Tue, 10 Dec 2002 15:33:02 -0500

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 10 Dec 2002 12:56:47 -0800

A charter requirement is that we be able to handle the case where the 
end device can use MIDCOM.  In order to do that realistically you will 
need an authentication infrastructure.  If it's not listed in the RFC it 
is a mistake.

I do not wish to rathole into whether SNMP's security model is 
sufficient for network management.  My opinion is well known.  However, 
the operating model and assumptions for network management protocols and 
user level access mechanisms is very different.  On the one hand, one 
may well want a mechanism that cannot fail if other network services 
fail.  On the other hand, we don't have that sort of operational 
environment here, and in fact, the architectural view we have allows for 
some sort of policy server for network services.

ON ITS OWN SNMP fails currently to address the case where you need to 
authenticate large numbers of current users one finds at an enterprise 
or university, because the key distribution mechanism provided is 
orthagonal to what is used today for user authentication of network 
services.    What does that today?  Radius.  The IETF presumably leans 
towards Diameter in the future.  The same problems persist with either.

Eliot
ps; could you send a documentation pointer to Kerberos integration w/SNMP?
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 10 Dec 2002 14:11:51 -0800

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
>
>
>

---

From: Melinda Shore <[email-masked]>
Date: Tue, 10 Dec 2002 17:28:43 -0500

I think people need to be clearer about whether or not they
think this is a show-stopper and why.  

Taking off my chair hat for a moment, I don't think it is -
there *is* a mechanism for carrying keying material and a
detailed description of the security mechanisms used by the
protocol.  Where the keys come from is outside the scope of
the existing documents.  The use of Kerberos or Radius could
be described in a midcom document if the protocol is
otherwise suitable.

Melinda

---

From: "Pyda Srisuresh" <[email-masked]>
Date: Tue, 10 Dec 2002 14:37:58 -0800

Eliot,

RFC 3303 does state explicitly that MIDCOM agent may reside on proxy
servers,
endhosts and application gateways. Yes, you are right about the requirement
to run  MIDCOM agents from end stations.

Registration and authentication of MIDCOM agents is also a requirement. But,
that
does not meant the MIDCOM protocol has to be akin to an authentication
protocol
such as RADIUS or DIAMETER.

You say, SNMP fails to address the case where you need to authenticate large
numbers
of current users. I don't see why authentication of large number of SNMP
sessions from
end users would be a problem on a middlebox. A Middlebox  may very well
choose
RADIUS or DIAMETER to perform its authentication.

Key distribution is orthogonal to the authentication process itself. Am I
missing something
Here?

Cheers,
suresh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Eliot
Lear
Sent: Tuesday, December 10, 2002 12:57 PM
To: Harrington, David
Cc: [email-masked]
Subject: [midcom] Re: key distribution

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 10 Dec 2002 14:44:40 -0800

Hi,

Pyda Srisuresh wrote:
> [snip]

And I entirely agree.  I would say that the MIDCOM protocol should 
easily integrate with such mechanisms just as you described.  My point 
is that SNMPv3 has NOT been demonstrated to do this, nor was the current 
USM engineered with this use in mind.  Furthermore, the key localization 
mechanism in USM may well be defeated by use of Diameter and Radius.  We 
could really do with a security person to comment more.

I am not sure it's a showstopper, but we ought to consider it.

Eliot