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

From: "David B. Nelson" <[email-masked]>
Date: Mon, 7 Jul 2008 15:12:33 -0400

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 8 Jul 2008 13:22:22 -0400

Bernard Aboba writes...

> Hints are inherently optional.

Well, quoting RFC 2119:

   MAY   This word, or the adjective "OPTIONAL", mean that an
   item is truly optional.

Since MAY means "truly optional", which I can't distinguish from "inherently
optional", I'm proposing to leave the text as is.  :-)

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 9 Jul 2008 15:52:55 -0400

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

I've taken the time to re-read RFC 5176.  It's not entirely clear to me if
and how Dynamic Authorization ought to apply to NAS management.  There's a
clear and straightforward application for Disconnect-Request, to terminate a
management session for administrative reasons.

I'm a little less clear that there is an application for
Change-of-Authorization for management sessions.  One could well imagine
possible, hypothetical use cases, of course.  The question remains whether
there is an actual user requirement to be met.  OTOH, I see no reason to
explicitly prohibit the usage of Dynamic Authorization with NAS Management
Authorization, especially if such usage is entirely optional.

RCF 5176 Section 2.3 (page 9, second to last paragraph) requests that future
documents defining RADIUS attributes specify the nature of their usage in
CoA or Disconnect messages, and whether each attribute can be used as a
session identifier, for session provisioning, or for both.

I will take a stab at that, and hereby solicit WG feedback on the proposal.

Add the following text to Section 12 (as currently numbered):

Change-of-Authorization Messages

   Request   ACK   NAK    #     Attribute

      0       0     0   TBA-2   Framed-Management-Protocol
      0       0     0   TBA-3   Management-Transport-Protection
      0-1     0     0   TBA-4   Management-Policy-Id (Note 2)
      0-1     0     0   TBA-5   Management-Privilege-Level (Note 2)

Disconnect Messages

   Request   ACK   NAK   #   Attribute

      0-1     0     0   TBA-2   Framed-Management-Protocol (Note 1)
      0-1     0     0   TBA-3   Management-Transport-Protection (Note 1)
      0       0     0   TBA-4   Management-Policy-Id
      0       0     0   TBA-5   Management-Privilege-Level

(Note 1) Where NAS or session identification attributes are included
   in Disconnect-Request or CoA-Request packets, they are used for
   identification purposes only.  These attributes MUST NOT be used for
   purposes other than identification (e.g., within CoA-Request packets
   to request authorization changes).

(Note 2) When included within a CoA-Request, these attributes
   represent an authorization change request.  When one of these
   attributes is omitted from a CoA-Request, the NAS assumes that the
   attribute value is to remain unchanged.  Attributes included in a
   CoA-Request replace all existing values of the same attribute(s).

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 10 Jul 2008 08:45:38 -0400

More follow up:

I could also envision permitting Framed-Management-Protocol and
Management-Transport-Protection as session identification attributes is a
CoA-Request, similar to their usage in a Disconnect-Request message.

 

I don't think it makes any sense to allow re-provisioning of the session
transport parameters, as that would almost certainly require a disconnect
and re-establishment of the session.

>    CoA-Request replace all existing values of the same attribute(s).

Similar logic applies to the Disconnect-Request case.  Those attributes
which might aid in distinguishing one of a user's concurrent sessions from
among others may be useful.  The primary indicator here is likely to be the
Service-Type, but that is already permitted by RFC 5176.  We only need to
discuss the newly introduced attributes, in this document.

I'm planning to crate a -04 version of the draft today, to submit prior to
the upcoming "blackout" period on ID submissions.  Now would be a good time
to submit comments on this issue (or any other open issue against -03).  :-)