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

From: Adrian Farrel <[email-masked]>
Date: Mon, 4 May 2009 18:56:48 +0200

Comment:
Table 2 says
   0    This attribute MUST NOT be present in a packet.
   0+   Zero or more instances of this attribute MAY be present in
        a packet.
   0-1  Zero or one instance of this attribute MAY be present in
        a packet.
   1    Exactly one instance of this attribute MUST be present in
        a packet.
   *    Only one of these atribute options SHOULD be included.

But:
- table 1 has no instance of 0+
- table 1 has no instance of 1
- * seems to contradict 0-1

---

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alexey Melnikov
> Sent: Sunday, May 03, 2009 8:44 AM
> To: [email-masked]
> Cc: [email-masked]; isms-
> [email-masked]
> 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).
> 
> 
> 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.
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

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

> From: Dave Nelson [mailto:[email-masked]]
> Sent: Tuesday, May 05, 2009 8:54 AM
> To: 'Adrian Farrel'; [email-masked]
> Cc: [email-masked]; draft-ietf-isms-radius-
> [email-masked]
> Subject: RE: COMMENT: draft-ietf-isms-radius-usage
> 
> Adrian Farrel writes...
> 
> > Subject: COMMENT: draft-ietf-isms-radius-usage
> >
> > Comment:
> > Table 2 says
> This table footnote is "standard boilerplate" for RADIUS documents.  It is
> traditionally included in its entirety even when not all of the elements
> are
> actually used in a particular document.  It's like including RFC 2119 in
> the
> references even though not all of the keywords are actually used in the
> document.  I don't think this will confuse anyone familiar with RADIUS
> RFCs.
> On the other hand, customizing the footnote for brevity would not cause
> any
> problems.
> 
> Once again, it is fairly common to indicate that one of a set of
> alternative
> attributes may be included in a RADIUS packet.  It's also common to use a
> footnote in the Table of Attribute to convey this information.  There is
> no
> actual contradiction here.  This could be expanded into a sentence (or
> two)
> for added clarity, but this usage is common to RADIUS documentation.

---

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

> Sent: Tuesday, May 05, 2009 9:06 AM
> To: 'Alexey Melnikov'; [email-masked]
> Subject: RE: [Isms] COMMENT: draft-ietf-isms-radius-usage
> 
> Alexey Melnikov writes...
> 
> Right.
> 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.