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

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

> -----Original Message-----
> From: Dave Nelson [mailto:[e-mail]]
> Sent: Tuesday, May 05, 2009 11:45 PM
> To: 'Eric Rescorla'; [e-mail]; [e-mail]
> Cc: [e-mail]; isms-
> [e-mail]
> 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.