Subject: RE: [Isms] I-D ACTION:draft-narayan-isms-sshsm-radius-00.txt

From: "Nelson, David" <[email-masked]>
Date: Mon, 26 Jun 2006 10:31:05 -0400

> The consensus was that we wanted an "authorize-only" RADIUS extension,
> to make RADIUS authorization independent of the authentication phase.

Let me approach this issue from another angle.

Along the continuum of WG goals, ranging from the unattainable "no new
software versions required" to the annoying "you need an upgrade to
everything", there are some interesting points to consider.

Everyone agrees that new SNMP software (manager and agent) will be
required to implement SSHSM.

There is a desire to leverage, but not impact, the existing AAA
infrastructures in wide deployment.  There are four levels of potential
impact that the ISMS works could have on RADIUS servers:

1. None at all.  The ISMS work simply uses existing facilities as they
exist in the field.

2. New attributes are needed that can simply be added to a data
dictionary file.  No new software version is required.

3. New attributes are needed and require a software version upgrade to
implement.  (This is distinguished from (3) by the server
implementation.)

4. A new authentication method is needed and requires a software version
upgrade.

I think the mandatory to document (and implement) levels are (1) and
(2).  The optional to implement levels are (3) and (4), which are
closely related.

I believe that "consensus" you speak of includes at least levels (3) and
(4).  The draft that we just submitted addresses (1) and (2), and
glosses over (3) and (4).  The authors recognize the desire to
effectively address these remaining issues, and will work to do so.
However, I see the current draft text as necessary to address the base
requirement for low impact integration methods.

I believe that there is likely to be a similar range of levels of impact
to the RADIUS client.  As this is co-resident with the SNMP agent in
most implementations, this may or may not be a concern.  Certainly the
level (1), no changes case would allow the RADIUS client to remain
unmodified.  There are unique deployment caveats and security
considerations that attach to the no change case, however.

Does this make any sense?  Comments, please.

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

---

From: "David Harrington" <[email-masked]>
Date: Mon, 26 Jun 2006 12:38:30 -0400

Hi,

There are basically two ways to use RADIUS with an SNMP engine.

The first is a relationship between RADIUS and SSH. The WG has reached
consensus that SSHSM should NOT be aware of the authentication
mechanisms used by SSH. It should not matter to SSHSM whether SSH uses
user/password, X.509, GSSAP, or RADIUS to authenticate the SSH client.
The decision to use a RADIUS backend is a configuration decision of
the deployer, and the configuration necessary depends on the SSH and
RADIUS implementations used.

The relationship between SSH and RADIUS at the lower layer should not
be visible to SSHSM.
Therefore, the impact that SSHSM has on RADIUS servers should be your
1) or 2), and the impact that using RADIUS to authenticate the SSH
client has on SSHSM should be "none at all". That deals with one usage
of RADIUS for SNMP. This interaction is between SSH and RADIUS and
should be totally independent of SSHSM.

In fact, the usage of RADIUS should not necessarily be dependent on
SSH, but might be dependent in exactly the same way if we were to use
a TLS lower layer that used RADIUS for authentication, or a BEEP lower
layer that used RADIUS for authentication. The SNMP transport model
and the SNMP security model should not care whether the lower layer
outsources the decision to a centralized RADIUS server.

Usage #1:
   A                    B
+--------+         +--------+        
| RADIUS |---------| SSH    |        
| Server |         | Client |   
+--------+         +--------+      

The other usage deals with a relationship between an SNMP access
control model, like VACM, and RADIUS. In this case, VACM (or its
encompassing ACM subsystem) talks directly to RADIUS to determine the
VACM (or other) configuration, such as Groupname to associate with the
known security-model-independent securityName. 

This interaction between VACM (or other ACM model) is totally
independent of SSHSM (or other security models). This usage should not
care whether SSH or TLS or UDP is used as the transport for SNMP
messages, and should not care whether the SNMP security model is SSHSM
or USM or some other model.

Usage  #2:
   A                    B
+--------+         +--------+        
| RADIUS |---------| VACM   |        
| Server |         | Model  |   
+--------+         +--------+      

So there are two different usages that could be described, and if the
WG wants them documented here they should either be in separate
documents or clearly described as two totally separate usages. SSHSM
should not even be mentioned in your document, because the SNMP
transport mapping, and the SNMP security model should be independent
of both RADIUS usages.

dbh

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Monday, June 26, 2006 10:31 AM
> To: David Harrington; [email-masked]
> Subject: RE: [Isms] I-D
ACTION:draft-narayan-isms-sshsm-radius-00.txt