Subject: RADEXT Issue 256 (NAS management Authorization)

From: "David B. Nelson" <[email-masked]>
Date: Tue, 10 Jun 2008 16:24:44 -0400

> Abstract
> 
> The current text is a bit wordy.  How about this? 
> 
>   This document describes Remote Authentication Dial-In User 
>   Service (RADIUS) attributes for the authorization and service
>   provisioning of Network Access Servers (NASes).  Both local and
>   remote management are supported, with granular access rights
>   and management privileges.  Specific provisions are made for
>   remote management via framed management protocols, and for
>   specification of a protected transport protocol.

Sounds good to me.  Will fix on -03.

> Section 7.1
> 
> I don't think you need to repeat much of Section 5.6 of RFC 2865.
> Why not just reference it instead?  Here is some recommended text
> for this section:
> 
> 7.1.  Service-Type
>
>   The Service-Type attribute is defined in Section 5.6 of RFC 2865
>   [RFC2865].   This document defines a new value of the Service-Type
>   Attribute:
>
>      (TBA)     Framed-Management
>
>      The semantics of the Framed-Management service are as follows:
>
>      Framed-Management   A framed management protocol session should
>                          be started on the NAS.

OK.  Will revise on -03.

> Section 8.1
> 
>   The Framed-Management-Protocol attribute indicates the application-
>   layer management protocol to be used for framed management access.
>   It MAY be used in both Access-Request and Access-Accept packets.
> 
> Please add a sentence explaining the semantics in this usage.  For
> example, in the Access-Request I assume that this Attribute describes
> the protocol that the client is using for remote administration. 

Yes.
 
> What does it mean in an Access-Accept?

The same thing that any other service provisioning attribute means -- start
the described service for the user's connection.  Typically these things are
decided by the RADIUS Server based on the user's account profile information
and any relevant hint attributes.

> For example, what does the NAS do if the value in the Access-
> Accept is different from the protocol that is being used?  Does
> it disconnect?

Yes.  It would also disconnect if the provisioned service is not supported
in the NAS.

How about the following for clarifying text?

It is RECOMMENDED that the NAS include an appropriately valued
Framed-Management-Protocol attribute in Access-Request packet, indicating
the type of access being requested, when the user requests a form of remote
management via a framed management application protocol.  It is further
RECOMMENDED that the NAS include a Service-Type attribute with the value
Framed-Management (TBA) in the same Access-Request packet.  The RADIUS
Server MAY use these hint attributes in making its authorization decision.

The RADIUS Server MAY include a Framed-Management-Protocol attribute in an
Access-Accept packet that also includes a Service-Type attribute with a
value of Framed-Management, when the RADIUS Server chooses to enforce an
management access policy for the authenticated user, that dictates one form
of management access in preference to others.

When a NAS receives a Framed-Management-Protocol attribute in an
Access-Accept packet, it MUST deliver that specified form of management
access or disconnect the session.  If the NAS does not support the
provisioned management application-layer protocol, or the management access
protocol requested by the user does not match that of the
Framed-Management-Protocol attribute in the Access-Accept packet, the NAS
must treat the response packet as if it had been an Access-Reject.

> Section 8.2
> What packets can this attribute be included in?  Access-Request & 
> Access-Accept?

Yes.  Also Accounting-Request for session logging purposes.

> What are the semantics in each case?  For example, in an 
> Access-Request is this the level of protection that is being used?

Yes.  This will be communicated to the RADIUS Client from the respective
management application, to the extent that application is aware of the
protection level of its underlying transport.

> What if the value in an Access-Accept is different (e.g. higher)
> than that in use?  For example, if confidentiality & integrity is 
> being requested, but the session is protected with TLS and an 
> integrity-only ciphersuite?  Is the session dropped?

Yes.  Do we need clarifying text, such as I proposed for the
Framed-Management-Protocol attribute (see above)?

Such clarifying text might read as follows:

It is RECOMMENDED that the NAS include an appropriately valued
Management-Transport-Protection attribute in Access-Request packet,
indicating the level of transport protection for the management access being
requested, when that information is available to the RADIUS Client.  The
RADIUS Server MAY use this hint attribute in making its authorization
decision.

The RADIUS Server MAY include a Management-Transport-Protection attribute in
an Access-Accept packet that also includes a Service-Type attribute with a
value of Framed-Management, when the RADIUS Server chooses to enforce an
management access security policy for the authenticated user, that dictates
a minimum level of transport security.

When a NAS receives a Management-Transport-Protection attribute in an
Access-Accept packet, it MUST deliver the management access over a transport
with equal or better protection characteristics or disconnect the session.
If the NAS does not support protected management transport protocols, or the
level of protection available does not match that of the
Management-Transport-Protection attribute in the Access-Accept packet, the
NAS must treat the response packet as if it had been an Access-Reject.
 
>   o  Confidentiality-Protection: The management session requires
>      protection in a secure or protected transport, that is supported
>      by the management access protocol and implementation.  The secure
>      transport MUST provide Confidentiality Protection.
>
> Does this option really make sense?  When would you want Confidentiality
> but not integrity? Isn't this dangerous?

This was discussed at IETF-71 and the proposal was to remove the
Confidentiality (only) option.  I propose to do that in the -03 version.

> Section 9
> 
> The examples use the Transport-Protocol Attribute, which is not
> defined in this document any more.

Editorial cruft.  Will fix in -03.

>  Also, please include the value of NAS-Port-Type in the examples.

OK.

> Section 11
> 
> I'd recommend moving this to a sub-section under Security 
> Considerations.

Hmmm.  Much of this discussion has impact on security, on the other hand, I
think that Proxy Considerations is a separate topic that justifies treatment
in a separate section, for emphasis.  I don't have a strong opinion on this,
but my initial reaction is to suggest that we leave it in a separate
section.

> Section 13
> 
> This section needs to be rewritten to list the new attribute for which 
> numbers being requested, as well as the new value for Service-Type.

So, you're suggesting that I not expect IANA to search through the document
for all the (TBA) placeholders, but rather enumerate all the requests here?
OK, I can do that in version -03.

All other comments in Issue 256, not otherwise discussed here are accepted
and will appear in the -03 version.

--
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: Bernard Aboba <[email-masked]>
Date: Wed, 11 Jun 2008 09:18:39 -0700

> must treat the response packet as if it had been an Access-Reject.

[BA] Should this be "MUST"?  Presumably if the NAS supports the new Service-Type,
then it is also required to understand the Framed-Management-Protocol attribute
and take the above action in response to an unsupportable value.  

> Management-Transport-Protection attribute in Access-Request packet,
                                                                     ^an

> NAS must treat the response packet as if it had been an Access-Reject.

"must" -> "MUST" as above. 

Also, I'd suggest capitalizing the word "Attribute" when referring to a specific
attribute, as was the custom in RFC 2865. 

> OK, I can do that in version -03.

Yes.  This makes it easier for them.

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 11 Jun 2008 20:34:23 -0400

One of the comments in Issue 256 was to add references for all of the
management protocols (methods?) enumerated for the
Framed-Management-Protocol Attribute in Section 8.1

In researching stable references, I discovered two issues:

(1) Some of these don't have good, stable references, such as standards
documents, but seem to be documented by UNIX "man pages".

(2) Some of these have supposedly been largely replaced in common usage.

The straw-man text that I now have looks like this:

   o  SNMP: Simple Network Management Protocol.  [RFC3411], [RFC3412],
      [RFC3413], [RFC3414], [RFC3415], [RFC3416], [RFC3417], [RFC3418]

   o  Web-based: Use of an embedded web server in the NAS for management
      via a generic web browser client.  The interface presented to the
      administrator may be graphical, tabular or textual.  The protocol
      is HTML over HTTP.  The protocol may optionally be HTML over
      HTTPS, i.e. using HTTP over TLS.

   o  NETCONF: Management via the NETCONF protocol using XML over
      supported transports (e.g.  SSH, BEEP, SOAP).  As secure transport
      profiles are defined for NETCONF, the list of transport options
      may expand.  [RFC4741], [RFC4742], [RFC4743], [RFC4744]

   o  FTP: File Transfer Protocol, used to transfer configuration files
      to and from the NAS.  [RFC0959]

   o  TFTP: Trivial File Transfer Protocol, used to transfer
      configuration files to and from the NAS.  [RFC1350]

   o  SFTP: SSH File Transfer Protocol, used to securely transfer
      configuration files to and from the NAS.  SFTP uses the services
      of SSH. (http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13)

   o  RCP: Remote CoPy file copy utility (Unix-based), used to transfer
      configuration files to and from the NAS.  RCP has bee largely
      replaced by SFTP.

   o  SCP: Secure CoPy file copy utility (Unix-based), used to transfer
      configuration files to and from the NAS.  SCP has been largely
      replaced by SFTP.

IIRC, RCP and TFTP were added to a previous draft version to resolve
previous review comments.  It is reported (e.g. Wikipedia) that SFTP is now
preferred to both RCP and SCP.

I would like to get some feedback from the WG prior to submitting the -03
version, as to whether:

(1) Are all of these methods of copying configuration files to a NAS in
current use?

(2) Are the cited references (or lack thereof) sufficient to our needs?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Jun 2008 06:23:53 +0200

>       configuration files to and from the NAS.  SCP has been largely

I am not sure there is evidence that scp has been largely replaced by
sftp. I suggest to simply remove the last sentence.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 12 Jun 2008 07:00:51 -0400

> sftp. I suggest to simply remove the last sentence.

What about RCP?  It is still in use, or has it been [somewhat | largely]
replaced by {SCP | SFTP}?

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 12 Jun 2008 18:32:23 +0700

> replaced by {SCP | SFTP}?

Does it really matter?  If they will be included in the list, just include
them w/o editorial comment (especially based upon a source like Wikipedia
;-).

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 12 Jun 2008 07:46:49 -0400

> Does it really matter?

If a protocol is no longer used, why bother include it in the list?

> If they will be included in the list, just include them w/o editorial
> comment...

Yeah, that sounds like good advice.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 12 Jun 2008 18:56:35 +0700

> If a protocol is no longer used, why bother include it in the list?

I'm sure somebody somewhere is using rcp (possibly even Kerberized) for
example, esp. if their NAS is *nix-based.  Why not?