Subject: [Isms] Keroberos Security Model for SNMPv3

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 7 Jul 2010 18:09:17 -0400

Hi,

We wrote a draft to present a centralized security model utilizing
Keroberos. Unfortunately, we missed the deadline for the IETF-78 submission.
We plan to submit the draft to the ietf system as soon as it opens up on
7/26. Meanwhile, please review the draft on the link given below:

http:/www.lee-networks.com/draft-pejaver-isms-kerberos-00.txt

Comments and thoughts are welcome.

Raj and Yiu

---

From: "David Harrington" <[email-masked]>
Date: Wed, 14 Jul 2010 17:51:40 -0400

Hi,

You might want to know that a Kerberos security model for snmpv3 was
developed around 1999 (IIRC).

I may have a copy of Ken Hornstein's draft if the WG is interested.

dbh 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Lee, Yiu
> Sent: Wednesday, July 07, 2010 6:09 PM
> To: [email-masked]
> Subject: [Isms] Keroberos Security Model for SNMPv3
> 
> Hi,
> 
> We wrote a draft to present a centralized security model 
> utilizing Keroberos. Unfortunately, we missed the deadline 
> for the IETF-78 submission.
> We plan to submit the draft to the ietf system as soon as it 
> opens up on 7/26. Meanwhile, please review the draft on the 
> link given below:
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 14 Jul 2010 22:53:46 -0400

Hi Dave,

You are right, we are aware of that draft. In fact, ours referenced heavily on it, we also added the centralized authorization. We think this is useful because Keroberos doesn't rely on session based transport. We didn't know the history why the Hornstein's draft wasn't accepted as WG item. Do you know why?

Thanks,
Yiu

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 14 Jul 2010 21:03:58 -0700

Hi -

> From: "Lee, Yiu" <[email-masked]>
> To: "David Harrington" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, July 14, 2010 7:53 PM
> Subject: Re: [Isms] Keroberos Security Model for SNMPv3
...
> we also added the centralized authorization.
> We think this is useful because Keroberos doesn't
> rely on session based transport.

Any thoughts on how this might work with the
AAA/Vacm integration?

> We didn't know the history why the Hornstein's draft wasn't
> accepted as WG item. Do you know why?

At the time of that draft (last update was in 2001) the isms
working group did not yet exist.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Thu, 15 Jul 2010 00:20:31 -0400

The snmpv3 wg wasn't chartered to work on additional security models
beyond USM: 
"The goal of the Working Group is to
produce the necessary set of documents that will provide a single
standard for the next generation of core SNMP functions."

We were trying to get snmpv3 stable and through the approval process
in 2001.

dbh

> Behalf Of Randy Presuhn
> Sent: Thursday, July 15, 2010 12:04 AM
> To: [email-masked]
> > We think this is useful because Keroberos doesn't rely on session 
> > based transport.
> 
> Any thoughts on how this might work with the AAA/Vacm integration?
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

From: "Pejaver, Rajaram" <[email-masked]>
Date: Mon, 26 Jul 2010 11:08:07 -0400

> Any thoughts on how this might work with the

The proposal suggests similar interpretation of the authorization data
returned from AAA/RADIUS.
However, the pathway for the authorization data is different.
Instead of the managed device talking to a RADIUS server, we suggest
that the Kerberos server
gets the authorization data from RADIUS (or an equivalent repository)
and inserts it securely into a ticket.

I can send out an explanation of the differences between the two
approaches.

Regards

Rajaram Pejaver  (Was on vacation:== Slow response)
Comcast, NETO

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Randy Presuhn
Sent: Thursday, July 15, 2010 12:04 AM
To: [email-masked]
Subject: Re: [Isms] Keroberos Security Model for SNMPv3

Hi -

...

Randy

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Jul 2010 18:47:31 -0400

> and inserts it securely into a ticket.

It's certainly possible to do that, but Kerberos has traditionally stayed 
away from the authorization space, and you might encounter some resistance 
getting KDC implementors to do something like that.

In any case, I am inclined to recommend use of SSHTM with GSS-krb5 keyex 
and/or userauth, rather than inventing a new SNMPv3 security model for this 
purpose.  An important part of the reason we chose SSH as the basis for the 
original ISMS work was to leverage its extensibility and wide range of 
existing authentication mechanisms to allow integration of SNMP with 
existing infrastructure _without_ developing new security models for every 
authentication scheme.

-- Jeff

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 27 Jul 2010 00:21:59 -0700

>>>>> On Mon, 26 Jul 2010 18:47:31 -0400, Jeffrey Hutzelman <[email-masked]> said:

JH> In any case, I am inclined to recommend use of SSHTM with GSS-krb5
JH> keyex and/or userauth, rather than inventing a new SNMPv3 security
JH> model for this purpose.  An important part of the reason we chose SSH
JH> as the basis for the original ISMS work was to leverage its
JH> extensibility and wide range of existing authentication mechanisms to
JH> allow integration of SNMP with existing infrastructure _without_
JH> developing new security models for every authentication scheme.

The downside of our existing choice to use a transport mechanism is that
it greatly ties the usage of the SNMP protocol to the underlying
characteristics upon which the transport is based.  EG, for SSH this
really means TCP which is not always appropriate for SNMP in some
environments (especially in lossy networks).  The addition of the (D)TLS
support helps this by allowing DTLS/UDP as a second alternative on a
different "base" protocol (UDP) with different delivery characteristics.

But if you recall the long history of the WG, the original proposal I
started the BOF with was a proposal that put the authentication inside
the SNMP packet so that it didn't tie the security to a particular
transport layer protocol.  I did this intentionally since Net-SNMP and
other stacks support SNMP over much more than just UDP and TCP.  Now, we
certainly don't need to revisit that discussion as a choice was made,
but fundamentally the choice we made very much restricted how SNMP
messages can be sent over the wire.

When Ken and I did the original KSM draft in 2001 (wow) we also made the
security tied only to the SNMPv3 message without requiring it be tied to
a particular underlying transport.  We also implemented it and have even
heard of a few real-world deployments of our original work (very few,
but non-zero).  I'm sure no one is actually doing KSM over anything but
UDP or TCP but in theory it's actually possible to do it over IPX,
AAL5PVC or even a unix domain socket.  I doubt it, but in theory it
should work.

Interestingly, one of the stumbling blocks at the time was
contextEngineID discovery.  Fortunately that's actually been solved now
with the creation of RFC5343.

In the end, though, we have significant real-world Kerberos use.  We
have real-world SSH use.  We have real-world TLS use.  Different people
need different forms of authentication and they likely want to use the
mechanisms they already have available over the transports they need to
use.  I'd love to see the KSM work go forward because I think it
helps complete the needs of another user base.  But, I also believe it
shouldn't be tied to the transport mechanism and thus it would be a
significant change in direction from the existing ISMS work.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 27 Jul 2010 03:52:11 -0400

Hi Jeff and Wes,

We are very much in alignment with Wes. In our network, we managed millions
of devices. We heavily rely on snmp to monitor/manage them. If we used
ssh-based snmp, it would be a challenge to manage millions of SSH (TCP)
sessions in term of scalability. (D)TLS is an alternative. As far as I know,
(D)TLS hasn't been widely deployed. We are open to evaluate the possibility
but snmp is our core tool, we can't risk to use (D)TLS until the technology
is proven and widely supported by the industry. In contrast, Kerberos is
mature and we use it in many places in our network. We believe Kerberos is a
better choice in our environment.

We are open to try any new technology and support the current works in ISMS,
but we also hope that ISMS can consider other alternatives based on
different use cases and requirements.

Thanks,
Yiu