Subject: RE: [Isms] Evaluation status

From: "Martin Soukup" <[email-masked]>
Date: Tue, 11 Jan 2005 08:56:54 -0500

I'm not an author, but I'd like to add my two cents on how I see the
priorities of these items.

> > 1) No provisions supporting two-factored authentication.

This is a major issue - and not just two-factor. For this solution to have
longevity it must support multi-factor authentication and should be composed
in such a way as to be extensible to N-form.

> > 2) SNMPv3's symmetric keys may be assembled from passwords (several
> > SNMP implementations require that they must be so assembled due to
> > symmetric key distribution problems). Such keys are no more secure than
> > the passwords they are derived from.

This is only true if the password is the complete key generation material.
If the key is generated from multiple key generation material of which the
password is a part this is not an issue. In either case, I don't think this
is of high importance since I suspect it would be advantageous for different
implementations to use different key material. In fact, I'd like to see a
way to integrate the proposal with an SSO system and use application session
tokens as key material for generating SNMP session keys.

> > 3) Key updates do not provide for Perfect Forward Security (PFS).

This is an important issue, probably about #3.

> > 4) There is an inherent problem with SNMPv3's Symmetric Key
> > distribution such that it is difficult to deploy multi-vendor SNMPv3
> > systems in a manner that is not operationally insecure. (Yes, I do know
> > about RFC 2786 but I note that it is an informational RFC that is not
> > universally implemented.)

What will make the product of this WG more successful?

> > 5) SNMPv3's session (i.e., privacy) keys are often default-deployed
> > in (security) non-viable ways.

If I understand this correctly, any proposal should include the inability to
function in a default key state? If so I think this is an easy-win
big-ticket.

> > 6) SNMPv3's symmetric keys are unique within a deployment (i.e.,
> > SNMP keys are unique to SNMP and are not integrated with any other IETF
> > protocol). Similarly, SNMPv3 cannot use any existing
> > authentication/authorization infrastructures already present in that
> > deployment (e.g., Kerberos, PKI, RADIUS, etc.).

This is the reason we're here, I think. 

One thing I haven't seen clearly in any of the three proposals is how to
allow authorization information to be exchanged during session key
establishment (a la typical RADIUS). Is this outside of the scope of the WG?
Did I miss it?

Martin.
_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 11 Jan 2005 06:55:06 -0800

>>>>> On Tue, 11 Jan 2005 08:56:54 -0500, "Martin Soukup" <[email-masked]> said:

>> > 1) No provisions supporting two-factored authentication.

Martin> This is a major issue - and not just two-factor. For this
Martin> solution to have longevity it must support multi-factor
Martin> authentication and should be composed in such a way as to be
Martin> extensible to N-form.

This would certainly be nice.  One caveat that I feel obligated to
mention:  Adding multi-factor authentication generally complicates the
protocols that support it.  This is primarily because of the sudden
need to have N*2 packet exchanges in order to complete the
authentication state, which means adding more state and makes the
state diagram tree more complex.  I'm not saying its not worth doing,
but it does come at a cost.

Martin> One thing I haven't seen clearly in any of the three proposals
Martin> is how to allow authorization information to be exchanged
Martin> during session key establishment (a la typical RADIUS). Is
Martin> this outside of the scope of the WG?  Did I miss it?

It was discussed some at the last meeting.  It is out of scope,
however.  Ideally the solutions shouldn't do something to get in the
way of the above, but the specific goal is not in the charter of the
group and would need to be added.

-- 
Wes Hardaker
Sparta

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 11 Jan 2005 10:53:28 -0500

Hi,

For those interested in RADIUS authorization for network management
interfaces, see
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-nelson-radius-
management-authorization-00.txt. Dave Nelson and I have been
discussing this approach for a while.

This proposal would be useful for all management interfaces. It could
be a uniting factor between management interfaces for CLI, NETCONF,
SNMP, and web-based interfaces, using similarly-named policies that
have different methods of implementation for different management
interfaces. It could also be a uniting factor across vendor products,
using similarly-named policies that have different methods of
implementation for different vendors' equipment. (To be clear, the
per-vendor/per-mgmtinterface "methods of implementation" would be
configured by operators.)

This is similar to the RFC 3580 approach which binds IEEE 802.1X
network access with RADIUS authentication and the passing of a RADIUS
FilterID to authorize different types of access (in RFC 3580, services
are provisioned to VLANs, and the FilterID authorizes user access to
the VLAN).

One goal is to use it with SNMPv3, using a RADIUS message to
dynamically define the association between an authenticated security
principal (vacmSecurityName) and a vacmGroupName. With pre-provisioned
groups having VACM access control, the RADIUS Management-Policy-ID
provides the glue between the user authentication and user
authorization to management information/operations. 

While the standardization of VACM makes this pretty straightforward
for SNMPv3, similar functionality could be used to associate the user
with proprietary (or TBD) mechanisms that control CLI authorizations,
web-based mgmt authorizations, and NETCONF authorizations.

The RFC 3580/ IEEE 802.1X/RADIUS approach to network access appears to
be getting wide deployment, and using a simlar approach for mgmt
access would seem to be a big win. That's why I personally would like
to see the EUSM proposal, or something similar, be advanced.

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Wes Hardaker
> Sent: Tuesday, January 11, 2005 9:55 AM
> To: Martin Soukup
> Cc: [email-masked]
> Subject: Re: [Isms] Evaluation status
>

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 11 Jan 2005 12:49:47 -0800 (PST)

HI,

I read ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-nelson-radius-
management-authorization-00.txt and see NOTHING about about
the proposal that helps EUSM. I believe that EUSM
wouldn't really support that the proposal that well, but I
would have to carefully re-read the EUSM proposal to come
to a statement of fact.

On the other hand, SBSM could use the 
...radius-management-authorization...
proposal pretty easily. However, Wes and I thought that solving
one part first was a better approach than also working on 
authorization modifications.
That part was to design a framework based on lightweight sessions
over UDP that allowed integration with any and all existing endpoint
identity authentication mechanisms. With a session approach,
one can afford the overhead of a once per session retrieving
authorization rules (policy). With SBSM, the security charateristics
of the sessions are better than those in USM.

I believe that the SBSM approach is lower in cost to develop and
deploy, and then later to extend and deploy by a large margin
over EUSM.

On Tue, 11 Jan 2005, David B Harrington wrote:
> <stuff cut>
Again, I don't see how it follows that EUSM works "better" than
SBSM. Would you explain how you got to this conclusion.

Regards,
/david t. perkins

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 11 Jan 2005 14:00:46 -0800

Hi David,

  EUSM has already a concrete proposal to complement the SNMPv3
VACM model. EUSM describes the use of the groupName attribute to supply
group Names for authenticated users. This will allow VACM to tie the
authenticated user to VACM policies locally defined on the agent.

I think the management authorization proposal intends to something
similar with the Management-Policy-Id attribute to pass down
roles/views to managed elements.

regards,
   kaushik!

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 11 Jan 2005 17:42:20 -0500

Hi Dave,

Were you reading the mail I sent?

I don't think I said that the radext proposal **helped** EUSM. 
But I do think EUSM section 3.2 fits especially well with the RADIUS
management-policy-id proposal. 
In EUSM, they refer to a groupname attribute to be used with VACM. 
In radext, they are looking to standardize an attribute that could
contain a groupname that could be used with VACM.

The other proposals could use use RADIUS and a management-policy-id
attribute as well, but neither discusses doing so. 
SBSM says working with RADIUS is a goal, but also seems to conclude
that working with RADIUS simply won't work - "Several approahces were
considered, but none were determined workable." If this is true, how
will SBSM utilize a RADIUS management-policy-ID?

I don't think I said "EUSM works 'better' than SBSM"; you extrapolated
that conclusion. On the other hand, I also did not say that SBSM works
better than EUSM. 

I said I would like to see EUSM, or something similar,  advanced.  I
think EUSM does a better job of integrating with existing
infrastructures that are achieving wide deployment, such as those
described in RFC 3580 and those used for securing wireless access
points. I think the EUSM proposal and the TLS proposal explicitly
mention an issue I consider important - the ability to use a common
identity across management interfaces, something not mentioned in the
SBSM document. So from the standpoint of integrating with existing
solutions, I personally favor EUSM or something similar.

dbh

> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Tuesday, January 11, 2005 3:50 PM
> To: David B Harrington
> Cc: 'Wes Hardaker'; 'Martin Soukup'; [email-masked]
> Subject: Re: [Isms] Network management authorization
> 
> HI,
> 
> I read 
>