RE: Additional comments on draft-ietf-radext-management-authorization-03.txt

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Bernard Aboba writes...

> Section 8.1
> 
> "Service-Type of Framed-Management" -> "Service-Type Attribute
> with the value Framed-Management"

OK.
 
> "in Access-Request packet" -> "in an Access-Request packet"

OK.

> "MAY use these hint attributes" -> "may use these attributes as a hint"

OK, but why "MAY" --> "may"?

> "MUST treat the response" -> "MUST treat the Access-Accept"

OK.

Reference issues have been previously discussed.

> Section 8.2
> 
>    The Management-Transport-Protection Attribute specifies whether a
>    secure transport protocol (e.g.  SSH, TLS, DTLS, etc.) is required
>    for use with the associated framed or non-framed management access
>    session.  The value of this attribute specifies the minimum level of
>    protection that is required from the protected transport.  The
>    protected transport MAY provide a greater level of protection than is
>    called for by the value of Management-Transport-Protection.
> 
> [BA] The second sentence is more on target.  How about this?
> 
>    The Management-Transport-Protection Attribute specifies the minimum
>    level of protection that is required for a protected transport used
>    with the framed or non-framed management access session.  The protected
>    transport used by the NAS MAY provide a greater level of protection,
>    but MUST NOT provide a lower level of protection.

OK.
 
> "in Access-Request packet" -> "in an Access-Request packet"
> "RADIUS Client" -> "RADIUS client"
> "RADIUS Server" -> "RADIUS server"
> "MAY use this hint attribute" -> "may use this attribute as a hint"

OK, but same question on "MAY"...

> Section 8.3
> 
> "application to SMNP services" -> "SNMP"
> "NAS behavior in such cases is not predictable." -> "The behavior of the
> NAS in this case is undefined."
> "a single service provisioning message, such as" -> "an Access-Accept or
> CoA-Request".

All OK.

> ", within a flat namespace of significance to the NAS"
> 
> [BA] Are you saying that "." can't be used?  Can this be deleted?

Eh?  By "flat", I mean a monolithic name that can be searched by a
non-structured text comparison (e.g. strcasecmp()).  This is effectively a
prohibition on sub-fields within the name text that a client or server would
need to take special heed of.  You can include ".", but it has no more
significance than any other character.

> "Overloading or subdividing this flat name with" ->
> "Overloading or subdividing this attribute with"

Hmm.  Module the resolution of the "flatness" issue, above, this might be
OK.

> "If a simple flat policy name" -> "If a simple policy name"
> "sufficient to the anticipated use case" -> "sufficient"

Ditto.
 
> Section 12
> 
> Within the document, the CoA-Request is mentioned, but the table
> does not describe which attributes can be included in CoA or
> Disconnect Request, ACK or NAK packets.  Is it accurate to assume
> that none of the attributes defined in this document can be 
> contained in a CoA or Disconnect packet?

Good question.  I need to think about this for a bit.

> Section 14
> 
>    Any of the attributes described in this memo, with the exception of
>    Service-Type, may not be understood by the NAS which receives it.  A
>    legacy NAS not compliant with this specification may silently discard
>    these attributes while permitting the user to access the management
>    interface(s) of the NAS.  This can lead to users improperly receiving
>    unauthorized management access to the NAS, or access with greater
>    levels of access rights than were intended.  RADIUS servers SHOULD
>    attempt to ascertain whether or not the NAS supports these attributes
>    before sending them in an Access-Accept.
> 
> [BA] This paragraph could be more clear.  There are really two cases.
> When a Service-Type value of Framed-Management is used, I'd assume 
> that a NAS implementing this specification would be required to behave
> as specified (e.g. treat the Access-Accept as an Access-Reject if the
> attribute or value wasn't supported).

Right.  Service-Type is the one implicitly "mandatory" (as in the Diameter
Mandatory bit) attribute in RADIUS.

Can we assume that if the NAS supports a value of Framed-Management for the
Service-Type attribute that it also at least *recognizes* all the other
Framed Management related attributes in this document, even though it may
not support those services?  Or is that expecting too much?

> I think that an issue could occur when a legacy Service-Type value
> is used though, since then the NAS might ignore the new attributes 
> instead of treating the Access-Accept like an Access-Reject.

Um, yeah.

> I don't think you need to talk about the potential behavior of an
> implementation that claims to conform to the spec, but doesn't do 
> what it says.

:-)

How about:

  A legacy NAS may not recognize the attributes in this document
  that supplement the provisioning of CLI management access.  If
  the value of the Service Type Attribute is NAS-Prompt or 
  Administrative, the legacy NAS may silently discard such 
  attributes, while permitting the user to access the CLI
  management interface(s) of the NAS.  This can lead to users
  improperly receiving unauthorized management access to the NAS,
  or access with greater levels of access rights than were intended.
  RADIUS servers SHOULD attempt to ascertain whether or not the
  NAS supports these attributes before sending them in an 
  Access-Accept provisioning CLI access.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>