[Isms] FW: COMMENT: draft-ietf-isms-radius-usage

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

> -----Original Message-----
> From: Dave Nelson [mailto:[e-mail]]
> Sent: Tuesday, May 05, 2009 9:06 AM
> To: 'Alexey Melnikov'; [e-mail]
> Cc: [e-mail]; isms-
> [e-mail]
> Subject: RE: [Isms] COMMENT: draft-ietf-isms-radius-usage
> 
> Alexey Melnikov writes...
> 
> > Subject: [Isms] COMMENT: draft-ietf-isms-radius-usage
> >
> > Comment:
> > 2.3.  SNMP Service Authorization
> >
> >  [...]
> >
> >    There are no combinations of RADIUS attributes that denote the
> >    equivalent of SNMP noAuthNoPriv access, as RADIUS always involves the
> >    authentication of a user (i.e. a principal) as a prerequisite for
> >    authorization.  RADIUS can be used to to provide an "Authorize-Only"
> >
> > Extra "to".
> >
> >    service, but only when the request contains a "cookie" from a
> >    previous successful authentication with the same RADIUS server (i.e.
> >    the RADIUS State Attribute).
> 
> Right.
> 
> >
> > 5.  Security Considerations
> >
> >  [...]
> >
> >    The Message-Authenticator (80) attribute [RFC3579] SHOULD be used
> >    with RADIUS messages that are described in this memo.
> >
> > Some explanation of why would be helpful here.
> 
> It is useful because the Message-Authenticator Attribute is the best
> available mechanism in RADIUS as it stands today to provide tamper-evident
> integrity protection of the service provisioning attributes in an
> Access-Accept packet.  It is slightly less important for Access-Request
> packets, although it may be desirable to protect any "hint" attributes
> contained in those messages.  This protection mitigates the fact that
> RADIUS
> messages are not encrypted and attributes could be added, deleted or
> modified by an adversary in a position to intercept the packet.
> 
> This is all pretty standard RADIUS Security Considerations material, and
> could be shortened to a brief explanation for inclusion in this draft.