Re: [secdir] Review of draft-ietf-isms-radius-usage-05

["Dave Nelson" <[e-mail]>]

Eric Rescorla writes...

> Subject: Review of draft-ietf-isms-radius-usage-05

Thanks for your review and comments.

> IMO, this document would benefit from a rewrite that makes it a
> lot clearer to someone not enmeshed in the WG.

Umm.  OK.  That's a bit disheartening to hear, but useful feedback.

> As far as I can tell, the idea is to explain how to outsource 
> some of the authorization decisions to RADIUS.

Correct.

> I found this document extremely difficult to read. I realize that
> the intended audience is for people with a lot of RADIUS and
> SNMP experience...

That's true.  Those are the intended audiences.  Additional explanatory
material was added to give each group some background information.

> ...but despite some familiarity with them, I had
> to work fairly hard to figure out what it was trying to say
> and I'm still not sure. This document would benefit very greatly
> from a diagram explaining how the authors think things are 
> supposed to work.

Diagrams can be useful.  We can certainly think about what might be helpful
in that regard.

> My big question is how the user authentication decisions are
> expected to be split between (e.g., SSH), and RADIUS. For
> example:
> 
> - If the user has a password, who checks it the RADIUS server
>   or the NAS? RADIUS certainly can do this.

The RADIUS server makes the authentication decision.  If the credential is a
password, as is the typical use case, the password is sent (hidden) in a
RADIUS Access-Request message.

> - If the user is authenticating with SSH pubkey auth, who
>   checks that?

The SSH server, i.e. the NAS.  SSH is used to create a protected transport
session (a tunnel, if you will) and the RADIUS credentials are obtained from
the SSH server implementation in the NAS and used by the RADIUS client in
the NAS to authenticate the user with the RADIUS server.  Of course, it has
to be an authentication method that RADIUS supports, and SSH public key is
not one of those.

> These seem like important architectural issues but I'm not getting
> them out of the document, and they should in particular
> be in the security considerations.

I'll re-read the document with your questions in mind.  Of course, as a
draft author and a RADIUS expert, I may have overlooked some unstated
assumptions.

> S 2.
> I don't understand what the difference is between service authorization
> and access control in this context.

Service Authorization means that the user is authorized to (a) manage the
NAS and (b) use SNMP in particular as the management mechanism.  Access
Control Authorization relates to the SNMP Access Control Subsystem and could
be thought of as analogous to access control lists or packet filters or any
similar fine-granularity access control mechanism.
 
> S 2.3.
> I don't get the SHOULDs here. If you're defining how code points are
> set, why are these optional?

OK, let's look at each one of these:

   RADIUS servers compliant to this specification SHOULD use RADIUS
   service provisioning attributes, as described herein, to specify
   SNMP access over a secure transport.

This one could arguably be a MUST.  In fact, I tend to think it ought to be
a MUST.

   The following RADIUS attributes SHOULD be used, as hint attributes
   included in the Access-Request message to signal use of SNMP over
   a secure transport (i.e. authPriv) to the RADIUS server:

RADIUS documents have traditionally held that appropriate "hint" attributes
are desirable in an Access-Request message, but that they are optional.
This preserves that tradition.  I suppose this could be changed to MUST
without impacting interoperability with RADIUS servers, which are always
free to ignore such hints.