Subject: I-D Action:draft-ietf-radext-management-authorization-02.txt

From: [email-masked]
Date: Sun, 24 Feb 2008 21:00:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management
	Author(s)       : D. Nelson, G. Weber
	Filename        : draft-ietf-radext-management-authorization-02.txt
	Pages           : 20
	Date            : 2008-02-24

This document describes Remote Authentication Dial-In User Service
(RADIUS) attributes for the authorization and service provisioning of
local and remote management of embedded systems and other managed
entities, generally referred to as Network Access Servers (NASes).
Specific provisions are made for remote management via framed
management protocols, for granular levels of access rights and
management privileges, and for specification of a protected transport
protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-02.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-radext-management-authorization-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-management-authorization-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 25 Feb 2008 08:52:45 -0500

> 	Title           : Remote Authentication Dial-In User Service
> (RADIUS) Authorization for Network Access Server (NAS) Management

I'm forwarding a list of the open issues that I culled from the RADEXT
mailing list, in preparing the -02 version of this draft.  All of the open
issues listed below have been addressed in one fashion or another.

I would like to call attention to one change in particular.

One particularly thorny issue with the -01 draft is the relationship (or
lack thereof) between the application layer management protocols, as
provisioned in the Framed-Management-Protocol attribute, and the protected
transport protocols, as provisioned in the Management-Transport-Protocol
attribute.  Part of the confusion is whether the latter attribute should
include "traditional" Layer 4 network transports (e.g. TCP, UDP, SCTP, etc.)
or only "protected transports" (TLS, DTLS, SSH, etc.)  The other part of the
confusion is which transports can be use with which management applications.

I think the -01 version suffers from "creeping complexity", caused partly by
various review comments along the way, and partly by muddled thinking on my
part.  Having been away from this document for some months, it occurred to
me that the problem was that the Management-Transport-Protocol attribute was
simply over-specifying the problem.  I don't think that anyone really needs
to micro-manage the choice of protected transport protocol, any more than we
need to micromanage the selection of remote terminal protocol in providing
the NAS-Prompt service.

The resolution to this particular set of comments was to change the
attribute to Management-Transport-Protection, and only provision that which
is important -- the level of protection required for the remote management
session.  The four possible values of this attribute are:

   o  No-Protection: No transport protection is required.  Accept
      connections via any supported transport.

   o  Integrity-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 Integrity Protection.

   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.

   o  Integrity-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 both Integrity Protection and
      Confidentiality Protection.

The complete list of issues addressed in the -02 revision is as follows:

-- Further explain the distinction between web-based management (HTML over
HTTP) vs. other methods, such as NETCONF (XML over HTTP).

Done.

-- Provide informational text listing the "default" transport for each of
the management protocols specified by Framed-Management-Protocol (e.g. for
SNMP it's unprotected UDP).

The "default" transport is no longer at issue.  The
Management-Transport-Protocols attribute has been re-cast as the
Management-Transport-Protection attribute.

-- Further explain what protocols (e.g. telnet, rlogin) are involved in
providing the NAS-Prompt Service-Type with each value of
Management-Transport-Protocol.

No longer applicable.

-- Explain the current remote console usage model of NAS-Port-Type of
Virtual with Service-Type of NAS-Prompt.

Done.

-- Should Management-Privilege-Level apply to Framed-Management-Protocol?
E.g. for access control of SNMP or NETCONF?

No.  Done.

-- Would the locally stored policies referenced by Management-Policy-Id ever
be too complicated to be stored on the NAS, requiring multiple policy and
access control attributes from the RADIUS server to express that complexity?

No.  Done.

-- Clarify the "local scope" of policy definitions on the NAS referenced by
Management-Policy-Id?

Done.

-- The proposed RADIUS attributes do not carry what really counts - the
security level, e.g. I might accept SNMP access as long as the actual
security level is providing authPriv, regardless how this is achieved.

Done?  I think the Management-Transport-Protection attribute addresses this
issue.

-- The two new attributes Framed-Management-Protocol and Transport-Protocol
are enumerations that may need to be extended (e.g. NETCONF is missing in
the first one already). I suggest that the IANA section spells out the rules
for extending these enumerations, e.g. by requiring a specification.

Done.

-- Are HTTP and HTTPS really two different framed management protocols? Or
is HTTPS just HTTP with a transport of TLS?

Done.

-- I do not think SSH really carries telnet in the sense of the telnet
protocol.

Done.

-- Would it be possible to indicate CLI access via telnet over tls?

No longer applicable.

-- I think that the way you would specify the secure remote terminal service
of SSH would be using Service-Type=NAS-Prompt,
Management-Transport-Protocol=SSH.

No longer applicable.

-- With respect to TLS/DTLS, what mode is intended?  Mutual auth with certs?
Server-only auth?  TLS-PSK?

No longer applicable.

-- I thought you need to specify what "default" means for each 
Framed-Management entry.

No longer applicable.

-- The NAS-Prompt Service-Type works for all of: local console
connections, telnet, rlogin, ssh, (and more) remote connections.

Done.

-- The only thing we are trying to specify here is whether the remote
terminal service is being carried over a secure transport.  Do we really
care what the transport layer protocol is?  I think that what we care about
is whether it over a secure or non-secure transport.

Done.

As always, further comments are welcome.  Hopefully you will find that this
draft version has addressed your open issues in a satisfactory manner.

--
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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Feb 2008 11:46:43 +0100

>       Confidentiality Protection.

I like the general approach.

I am wondering however how authentication fits into the above list or
whether you assume integrity-protection and confidentiality-protection
imply authentication of the two parties involved.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Feb 2008 13:33:35 +0100

> imply authentication of the two parties involved.

I now realize that my comment is kind of stupid since the fact that
there is a RADIUS request kind of implies authentication happening.

/js

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 26 Feb 2008 08:18:59 -0500

Juergen Schoenwaelder writes...
 
> > The resolution to this particular set of comments was to change 
> > the attribute to Management-Transport-Protection, and only 
> > provision that which is important -- the level of protection 
> > required for the remote management session.  The four possible
> > values of this attribute are:
> >

RADIUS is all about authentication.  That basic function of RADIUS has not
changed.  The RADIUS server authenticates the user (via one of the supported
authentication methods) before choosing to send an Access-Accept message.
If the RADIUS server chooses not to authenticate an actual user (e.g.
Call-Check) it would likely not authorize provision of a service that
required a protected transport.  (Although there may be valid uses case for
doing so...)

It is reasonable to assume that in any use case where authentication of the
user (e.g. the SNMP principal attempting to connect to the NAS) is
important, that receipt of an Access-Accept message at the NAS indicates
that the user has been authenticated by the RADIUS server.

What is not specified in this mechanism is a cryptographic binding between
the authenticated RADIUS user identity and the keys, certificates, or other
credentials used to establish the protected transport session.  The NAS may
be in a position to perform this "binding" by relating the authenticated
RADIUS user identity to some local transport session handle.  The details of
this would be a matter of implementation, I would think.

If the NAS is capable of determining, via its API to the transport security
layer, that a protected transport is in use and what its properties are, the
NAS is in a position or enforce the provisions of the
Management-Transport-Protection attribute.  If the NAS is not capable of
making that kind of determination (e.g. because of limitations in the APIs,
etc.), then the whole issue of requiring a protected transport is very
questionable, whether you call it out by name (e.g. SSH or TLS) or you call
it out by property (e.g. Integrity-Protection or
Confidentiality-Protection).

Does that line of thinking make sense to you?

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 26 Feb 2008 08:35:39 -0500

> there is a RADIUS request kind of implies authentication happening.

Ooops.  Response collision.  Sorry.  BTW, no comment is stupid, and all are
appreciated.