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

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

> -----Original Message-----
> From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On 
> Behalf Of Dave Nelson
> Sent: Wednesday, May 06, 2009 12:48 AM
> To: isms@ietf.org
> Subject: [Isms] FW: Review of draft-ietf-isms-radius-usage-05
> 
> > -----Original Message-----
> > From: Dave Nelson [mailto:d.b.nelson@comcast.net]
> > Sent: Tuesday, May 05, 2009 11:45 PM
> > To: 'Eric Rescorla'; secdir@ietf.org; iesg@ietf.org
> > Cc: draft-ietf-isms-radius-usage@tools.ietf.org; isms-
> > chairs@tools.ietf.org
> > 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.
> 
> _______________________________________________
> Isms mailing list
> Isms@ietf.org
> https://www.ietf.org/mailman/listinfo/isms
> 