RE: [Isms] Summary of Authorize Only issue

["Nelson, David" <dnelson@enterasys.com>]

Dave Harrington writes...

> I think "SNMP over SSH" would be appropriate. I do not see a reason to
> limit it to SNMPv3.

That's fine by me, if that's the consensus.  In the past, I've been
encouraged to omit support for v1 and v2c in I-Ds, as those versions
have been deprecated.  The comment was from Bert Wijnen, in relation to
protocol selection attributes I'd included for v1 and v2c in the
NAS-Management draft.

> >
> >       (b) Some other authentication mechanism/service
> >           provides initial authentication (and no
> >           authorization) of SNMPv3 over SSH.
> 
> Whether the other services provides authorization or not is
> immaterial.

Perhaps immaterial to RADIUS requirements, per se, but certainly not
immaterial to the security considerations for SNMP over SSH as a whole.

> >       (c) Some other authentication mechanism/service
> >           provides initial authentication (and no
> >           authorization) of SNMPv3 over SSH.  RADIUS
> >           provides base-service authorization of
> >           SNMPv3 over SSH (but no authentication).
> 
> I'm not sure anybody has asked for this combination, but I suppose we
> don't need to rule it out.

Included for completeness.  Wes H. has indicated, in a separate post,
that this might be useful.

> I would like to make sure everybody understands that the NAS is the
> managed device, not only edge devices providing network access
> services; Every SNMP-manageable device in the network might be
> considered a NAS in this scenario.

Yes.  In "RADIUS-speak", the terms "NAS" and "RADIUS Client" are often
used interchangeably.  In this use case, it would probably be desirable
to favor the term "RADIUS Client", for added clarity.

> Educate me. Why primarily the password authentication?

Because this is the RADIUS authentication method most commonly used for
SSH deployments today, I believe.

> Does this imply a (plaintext) password?

Yes, although RADIUS encrypts that password on the wire, on a hop-by-hop
basis, using the shared secret.

> Other authentication mechanisms might be preferable to passwords;
> I assume RADIUS supports a wide range of authentication mechanisms.

No, it does not.  The existing RADIUS authentication methods are:

-- password
-- textual challenge / response
-- CHAP (MD5 Digest)
-- EAP (basically any EAP method)
-- HTTP Digest (newly added)

We already know that EAP is not permissible for use with network
management authentication, because of its narrow applicability
statement.

Practically speaking, that leaves us with password and CHAP.  I believe
most of the current SSH usage of RADIUS for network management uses
password.

> I think there are three extended SNMP use cases that involve RADIUS
 
> 	  (c) RADIUS does not perform authentication or
>             base-service authorization.
>             Some other authentication mechanism/service
>             provides initial authentication and presumably
>             base service authorization for SNMP over whatever
>             secure transport, such as SNMP using USM over UDP,
>             or SNMP using USM and TCP/IPv6, or SNMP using Kerberos
>             and SCTP, or SNMP using 802.1AE and Ethernet.
>             The access control subsystem requests from RADIUS
>             ONLY the granular access control authorization
>             associated with the otherwise-authenticated user.
> 		(e.g., hey RADIUS, which group is this guy in?)

Juergen S., in a separate post, suggests that the two be collapsed into
one.  I'll ponder this a bit and propose something that attempts to
address both suggestions.
 
> Who sets the policy the RADIUS server will enforce?

The system administrator.

> i.e., how does the RADIUS server know which attributes contain
> security-sensitive information related to a user?

That is an implementation detail of the RADIUS Server, and not an
on-the-wire protocol issue.  I suggest that the document include
implementation guidance on this issue, perhaps in the security
considerations section, and that the protocol be designed so as to
provide sufficient information for an implementation to be capable of
accomplishing this goal.

It would certainly be possible to make a (non-exhaustive) list of
sensitive attributes, much as we make a list of sensitive objects in the
security considerations section of MIBs.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>