Subject: [Isms] FW: Review of draft-ietf-isms-radius-usage-05

From: "Dave Nelson" <[email-masked]>
Date: Wed, 6 May 2009 00:47:48 -0400

> -----Original Message-----
> From: Dave Nelson [mailto:[email-masked]]
> Sent: Tuesday, May 05, 2009 11:45 PM
> To: 'Eric Rescorla'; [email-masked]; [email-masked]
> Cc: [email-masked]; isms-
> [email-masked]
> Subject: RE: Review of draft-ietf-isms-radius-usage-05
> 
> 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.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 6 May 2009 08:44:08 -0400

Hi,

The term access control as used in AAA and as used in SNMP has always
been a problem. The MIB boilerplate always discusses that the MIB is a
virtual database. To help clarify the distinctiojnj when doiscussing
SNMP and AAA together, I recommend referring to SNMP access control as
"database access control" or "MIB database access control".

dbh

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dave Nelson
> Sent: Wednesday, May 06, 2009 12:48 AM
> To: [email-masked]
> Subject: [Isms] FW: Review of draft-ietf-isms-radius-usage-05
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>