Subject: Review of Management Authorization -00 document

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 05 Nov 2007 15:16:31 -0800

Section 3

   Framed Management means management of an entity by means of a non-
   interactive, non-CLI-style method.  The management information is
   typically formatted in a binary or textual protocol, such as HTTP or
   SNMP.  While remote management by interactive CLI sessions are
   carried over protocols, such as Telnet, Rlogin, and SSH, these
   protocols are primarily for the delivery of terminal, or pseudo-TTY
   services.  Command Line Interface, Menu Interface, or other ASCII
   (UTF-8) terminal emulation interfaces are not considered to be Framed
   Management protocols, as used in this document.  Examples of Framed
   Management protocols include HTTP, HTTPS, and SNMP.

   To support the authorization and provisioning of Framed Management
   access to managed entities, this document introduces a new value for
   the Service-Type attribute [RFC2865], and one new attribute.  The new
   value for the Service-Type attribute is Framed-Management.  The
   definition of this service is the provisioning of remote device
   management via a Framed Management protocol, as described in this
   section.  The new attribute is Framed-Management-Protocol, the value
   of which specifies a particular protocol for use in the remote
   management session.

This seems to imply that SSH would not be an acceptable value for
Framed-Management-Protocol.  Is that right?

Section 7.2

I am not clear that all combinations of Framed-Management-Protocol
and Transport-Protocol make sense.

For example, are the following combinations possible?

Example 1:

Framed-Management-Protocol = HTTPS/TLS (3)
Transport-Protocol != TLS (3)

Example 2:

Framed-Management-Protocol = HTTP (2)
Transport-Protocol = TLS (3)

How is this different from Framed-Management-Protocol = HTTPS/TLS?

Example 3:

Framed-Management-Protocol = SFTP (4) or SCP (5)
Transport-Protocol != SSH (2)

If Framed-Management-Protocol and Transport-Protocol are really orthogonal, 
then
I'd suggest that Framed-Management-Protocol not include any implied 
transports
and that the Transport-Protocol list be expanded.  For example:

Framed-Management-Protocol

1      SNMP
2      HTTP
3      FTP
4      CP

Transport-Protocol

1  UDP
2  TCP
3  SSH over TCP
4  TLS over TCP
5  TLS over UDP

Section 7.3

   The Management-Policy-Id attribute indicates the name of the
   management access policy for this user.  Zero or more Management-
   Policy-Id attributes MAY be sent in an Access-Accept packet.
   Identifying a policy by name allows the policy to be used on
   different NASes without regard to implementation details.

What does it mean if multiple Management-Policy-Id attributes are included?
How are the policies merged?  If this is implementation-specific, isn't
the result undefined?

Section 8

       *  Service-Type (6) = Administrative (6)
       *  Transport-Protocol (xx) = None (1)

Is the Transport-Protocol really none??

Section 9

   What this specification says about the applicability of the
   attributes for RADIUS Access-Request packets applies in Diameter to
   AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072].  What is said
   about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or
   Diameter-EAP-Answer [RFC4072] with Result-Code AVP set to
   DIAMETER_MULTI_ROUND_AUTH.

   What is said about Access-Accept applies in Diameter to AA-Answer or
   Diameter-EAP-Answer messages that indicate success.  Similarly, what
   is said about RADIUS Access-Reject packets applies in Diameter to AA-
   Answer or Diameter-EAP-Answer messages that indicate failure.

   What is said about COA-Request applies in Diameter to Re-Auth-Request
   [RFC4005].

I'm not clear that these statements make sense because there typically is
no authentication in these AAA exchanges, right?

Section 12

   This document contains placeholders ("TBA") for assigned numbers
   within the RADIUS Attributes registry, to be assigned by IANA at the
   time this document should be published as an RFC.  Assignement of
   additional values for attributes defined in this document are to be
   processed as described in [RFC3575].

RFC 3575 specifies "First come, first served", which requires no review.  Is
this really what you want?

--
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, 6 Nov 2007 10:37:20 -0500

I'm on the road currently, so I'll comment only briefly, and follow up later
in the week.

Thank you for the thoughtful and thorough review.

Regards,

Dave

> Framed-Management-Protocol.  Is that right?

SSH delivers a secure transport service and a remote login (terminal
emulation service).  That does not seem to be the same thing as a specific
management protocol, of which SNMP is the most obvious example.  Should SHH
(alone) be considered a framed management protocol, or should it be
considered a remote form of CLI access?

> and Transport-Protocol make sense.

I'll take a look at this in detail and follow up.

> How are the policies merged?  If this is implementation-specific, isn't

This issues was raided by others.  The proposed resolution is to threat it
in the same way as we treat Filter-Id in the Issues & Fixes draft, i.e.
multiple instances are NOT RECOMMENDED and the result is undefined.

> Is the Transport-Protocol really none??

Hmmm...

> no authentication in these AAA exchanges, right?

I'll take a closer look.  Probably wanton application of boilerplate text.
 
> RFC 3575 specifies "First come, first served", which requires no review.
> Is this really what you want?

Should we tighten up on some of these allocations, above any beyond the
provisions of RFC 3575?  I thought we didn't want to go down that path...

---

From: "David B. Nelson" <[email-masked]>
Date: Sun, 18 Nov 2007 11:56:28 -0500

Following up ....

> considered a remote form of CLI access?

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.

> > and Transport-Protocol make sense.

These sections will be revised in the -01 version.

> > Is the Transport-Protocol really none??

This will be changed to Default (1), which means use any supported
transport.

> > Section 9
> >
> > I'm not clear that these statements make sense because there typically
> > is no authentication in these AAA exchanges, right?

Well, these attributes can appear as hints in Access-Requests. I'll snip out
some of the unrelated boilerplate text, especially that relating to EAP.

---

From: "David B. Nelson" <[email-masked]>
Date: Sun, 18 Nov 2007 12:10:04 -0500

More follow up ...

> Framed-Management-Protocol

OK.  What I'm proposing in the -01 version is:

1      SNMP
2      Web-based
3      NETCONF
4      FTP
5      TFTP
6      CP

> 5  TLS over UDP

I don't think we want to be specifying the "real" transport layer, e.g. TCP,
UDP, SCTP, etc.  What we need to specify there is the "secure transport"
(which doesn't exactly fit into the classical ISO 7-layer model), e.g. SSH,
TLS, etc.

What I'm proposing for the -01 version is:

1      Default
2      SSH
3      TLS
4      DTLS
5      BEEP
6      SOAP

> How are the policies merged?  If this is implementation-specific, isn't

Proposed text for the -01 version:

</t>
No precedence relationship is defined for multiple occurrences of the
Management-Policy-Id attribute.  NAS behavior in such cases is not
predictable.  Therefore, two or more occurrences of this attribute SHOULD
NOT be included in a single service provisioning message, such as
Access-Accept or CoA.
<t>
</t>
The content of the Management-Policy-Id attribute is expected to be the name
of a management access policy of local significance to the NAS, within a
flat namespace of significance to the NAS.  Overloading or subdividing this
flat name with multi-part specifiers (e.g. Access=remote, Level=7) is likely
to lead to poor multi-vendor interoperability and SHOULD NOT be utilized.
If a simple flat policy name is not sufficient to the anticipated use case,
it is RECOMMEDNED that a Vendor Specific Attribute be used instead, rather
than overloading the semantics of Management-Policy-Id.
</t>

---

From: <[email-masked]>
Date: Sun, 18 Nov 2007 12:02:37 -0800

> OK.  What I'm proposing in the -01 version is:

What does Web-based mean?  Is it  something other than HTTP?

> What I'm proposing for the -01 version is:

What does default mean?  Insecure transport (e.g. TCP/UDP)?
Does SNMP over Default mean SNMP over UDP or TCP?

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

> than overloading the semantics of Management-Policy-Id.

This looks OK.

---

From: <[email-masked]>
Date: Sun, 18 Nov 2007 12:05:11 -0800

> Management-Transport-Protocol=SSH.

You might say that in the document.   Would Service-Type = NAS-Prompt and
Transport=TLS mean telnet over TLS?

---

From: "David B. Nelson" <[email-masked]>
Date: Sun, 18 Nov 2007 23:48:25 -0500

Bernard Aboba writes...

> What does Web-based mean?  Is it something other than HTTP?

No, but HTTP can be used for other things that a web page (HTML), for
example NETCONF (XML) over HTTP.  This was to distinguish "classic"
web-based management interfaces from other things that might use the HTTP
transport.

> What does default mean?  Insecure transport (e.g. TCP/UDP)?

It might mean that, assuming that the standard transport used is one of
those.  For example, for web-based management (HTML over HTTP) the default
transport is TCP.

> Does SNMP over Default mean SNMP over UDP or TCP?

The default transport for SNMP is UDP.

> Server-only auth?  TLS-PSK?

This document doesn't go into that level of NAS configuration detail.  Do
you think those parameters ought to be provisioned via RADIUS attributes?

---

From: "David B. Nelson" <[email-masked]>
Date: Sun, 18 Nov 2007 23:53:15 -0500

Bernard Aboba writes...

> > I think that the way you would specify the secure remote terminal
> > service of SSH would be using Service-Type=NAS-Prompt,
> You might say that in the document.

Yes.

From examples section of the -01 version, just now submitted:

2.  CLI access, via the secure remote terminal service of SSH, to the
       non-privileged user access level:

       *  Service-Type (6) = NAS-Prompt (7)
       *  Management-Transport-Protocol (xx) = SSH (2)

> Would Service-Type = NAS-Prompt and Transport=TLS mean telnet 
> over TLS?

It would probably mean telnet, although it could also mean some other form
of remote terminal service (e.g. rlogin).  It would certainly mean "over
TLS".

---

From: <[email-masked]>
Date: Sun, 18 Nov 2007 22:49:28 -0800

> web-based management interfaces from other things that might use the HTTP

OK.  You might say "HTTP/HTML" or something like that.

> those.  For example, for web-based management (HTML over HTTP) the default

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

> The default transport for SNMP is UDP.

Is it possible to specify SNMP over TCP?  TCP is not on the list of 
transports.

> you think those parameters ought to be provisioned via RADIUS attributes?

Personally, I prefer that they not be.  But without specifying exactly what 
is meant,
it's not clear what "TLS" means.  For example, you might say "TLS with 
server-side authentication".

---

From: <[email-masked]>
Date: Sun, 18 Nov 2007 22:50:31 -0800

> of remote terminal service (e.g. rlogin).  It would certainly mean "over

I think that the meaning needs to be well defined.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 19 Nov 2007 02:11:27 -0500

> > It would probably mean telnet, although it could also mean some
> > other form of remote terminal service (e.g. rlogin).  It would 
> > certainly mean "over TLS".
> 

Hmmm.  The NAS-Prompt Service-Type works for all of: local console
connections, telnet, rlogin, ssh, (and more) remote connections.  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
application layer protocol is?  I think that what we care about is whether
it over a secure or non-secure transport.

This feature relies on the authorization module of the NAS being aware of
the transport layer being used by the remote terminal connection, and
ensuring that it matches the provisioned parameters.

For SSH and TLS I believe that is possible.

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 19 Nov 2007 02:25:45 -0500

> OK.  You might say "HTTP/HTML" or something like that.

If that's more clear, then sure.  I though web-based management was pretty
clear, though.

> I thought you need to specify what "default" means for each

Oh.  That could easily be done, for ease of reference, although it is
normatively defined in other documents.

> Is it possible to specify SNMP over TCP?  TCP is not on the list of

No.  The enumerated values of the Management-Transport-Protocol attribute
are intended to describe the _secure_ transport (e.g. TLS), that sits on top
of the transport (e.g. TCP).  Why would it be valuable to be able to specify
the transport?

Should we have a better name for things like SSH and TLS than "secure
transport"?  Does that cause confusion with "classic" transports?

> Personally, I prefer that they not be.  But without specifying exactly
> what is meant, it's not clear what "TLS" means.  For example, you might
> say "TLS with server-side authentication".

One might say that.  Is it important to know how the TLS session keys were
derived or just that a TLS session is being used to protect the management
protocol?

I see this as supporting a high-level policy that system administrators use
protected methods of managing the NAS, as opposed to unprotected methods.

Do we need to go deeper than that?

---

From: <[email-masked]>
Date: Mon, 19 Nov 2007 05:45:28 -0800

> application layer protocol is?

In current usage, is it possible to send a Server-Type=NAS-Prompt attribute 
to a NAS
without a serial port?

As I recall, NAS-Prompt originally did not specify any "application layer 
protocol"
at all.   Wasn't the purpose to allow an admin connecting to a terminal 
server to
administer it over a serial connection?

Assuming that, I'm puzzled as to what it means to specify 
Server-Type=NAS-Prompt
along with an underlying framed transport, like TLS.  With the RFC 2865 
definition
of the NAS-Prompt service, when I hook a terminal emulator to a console 
port, or
dialin to a terminal server on a port, I'm going to get an unframed serial 
stream of bits
suitable for viewing on a terminal emulator.

Once I specify a Transport Protocol for NAS-Prompt, (say TLS) what am I 
going to get?
First off, this is a serial link, so I'd assume that if there is IP flowing 
over the link that
we need framing of some kind, either SLIP or PPP.  That seems intrinsically 
at odds
with a Service-Type=NAS-Port.

So I guess I don't understand the idea of running the NAS-Port or 
administrative service
over a Transport Protocol.  If we are talking about a framed management 
service, then
Servce-Type = Framed-Management seems like it makes more sense.

>I think that what we care about is whether it over a secure or non-secure 
>transport.

Does NAS-Prompt as defined in RFC 2865 have a transport?  I thought it was 
just
a non-frmaed serial stream of bits.

> ensuring that it matches the provisioned parameters.

When Service-Type=NAS-Prompt, there is no transport layer to be aware of 
right?

---

From: <[email-masked]>
Date: Mon, 19 Nov 2007 07:29:41 -0800

>> Wasn't the purpose to allow an admin connecting to a terminal
>> server to administer it over a serial connection?
>
> Yes, among other options.  I've always implemented NAS-Prompt and
> Administrative for access to the CLI, regardless of whether the connection
> was to the local console (e.g. serial RS-232) or via a remote terminal
> protocol (e.g. via telnet over TCP/IP.  Most NASes that I'm familiar with
> have a host-IP address and (at least) a telnet listener.

My experience with Service-Type=NAS-Prompt (if memory serves) was
for administering a NAS over a serial port, with authentication protected
by a token system.   As I recall, it was possible to utilize 
Service-Type=NAS-Prompt
alongside token authentication.

In those scenarios, I would guess that the NAS would send 
Service-Type=NAS-Prompt
in the Access-Request, along with no Transport-Protocol attribute.  If the 
user came in
via Telnet or SSH, the Transport-Protocol would change depending on what was 
used.
Is this more or less the usage model that is envisaged, where the NAS tells 
the RADIUS
server what type of access is being requested, and the server decides 
whether to
authorize it?

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 19 Nov 2007 13:25:12 -0500

> for administering a NAS over a serial port, with authentication 
> protected by a token system.   As I recall, it was possible to 
> utilize Service-Type=NAS-Prompt alongside token authentication.

That may well be one use case.  There are others.  Password authentication
is commonly used. The NAS-Prompt Service-Type has been used to authorize
local console access to the CLI as well as remote console access to the CLI.
Many implementations distinguish the two cases by the value of
NAS-Port-Type, which may be Async (0) for the physical console or Virtual
(5) for any form of remote console (e.g. telnet, shh, rlogin, et. al.).

> Service-Type=NAS-Prompt in the Access-Request, along with no
> Transport-Protocol attribute.  If the user came in via Telnet or
> SSH, the Transport-Protocol would change depending on what
> was used.

The Management-Transport-Protocol attribute could certainly be used in
conjunction with the NAS-Port-Type attribute of Virtual (5), as is the
current practice.

> Is this more or less the usage model that is envisaged, where
> the NAS tells the RADIUS server what type of access is being 
> requested, and the server decides whether to authorize it?

Yes, that's an important element of this proposal.  Just because someone is
authorized to obtain network service from the NAS doesn't mean they are
authorized to manage the NAS.  If a single RADIUS server (or set of
primary/backup servers) is used to handle all authentication requests, it is
important for the server to be able to authorize management access only for
those in the system administration group.

In that sense, the usage of the Management-Transport-Protocol attribute
usage as a hint is as important, or more important, than the provisioning
usage.

Do you think it is important to have an attribute that says "telnet" or
"rlogin" in addition to one that says "over SSH" or "over TLS"?

---

From: <[email-masked]>
Date: Mon, 19 Nov 2007 16:52:59 -0800

> is commonly used.

What attributes go along with that?  User-Password?  CHAP-Password?

>The NAS-Prompt Service-Type has been used to authorize

OK.  My memory is returning...

> conjunction with the NAS-Port-Type attribute of Virtual (5), as is the

OK.  It would make sense to say that in the document;.  Is there a situation
where  NAS-Port-Type = Async (0) would make much sense along with
a Management-Transport-Protocol, attribute?

> usage as a hint is as important, or more important, than the provisioning

OK.  It might be useful to have an example or two to make this clear.

> "rlogin" in addition to one that says "over SSH" or "over TLS"?

The scenario here is to provide more info in the case where 
NAS-Port-Type=virtual,
and Server-Type=NAS-Prompt, right?  I guess there are scenarios where this
could make a difference to the RADIUS server (e.g. router mistakenly enables
an insecure management protocol and RADIUS server wants to make sure it
that only secure protocols are authorized).

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 19 Nov 2007 22:39:03 -0500

> What attributes go along with that?  User-Password?  CHAP-Password?

For the Access-Request, it is usually User-Name and User-Password, although
I suppose CHAP-Password is possible.

> > The Management-Transport-Protocol attribute could certainly be 
> > used in conjunction with the NAS-Port-Type attribute of Virtual 
> > (5), as is the current practice.
> 
> OK.  It would make sense to say that in the document.

That can easily be added, as explanatory material. 

> Is there a situation where NAS-Port-Type = Async (0) would make 
> much sense along with a Management-Transport-Protocol, attribute?

No.  That should also be called out in the document.

> > usage as a hint is as important, or more important, than the
> > provisioning usage.
> 

OK.

> NAS-Port-Type=virtual, and Server-Type=NAS-Prompt, right?  I guess
> there are scenarios where this could make a difference to the RADIUS
> server (e.g. router mistakenly enables an insecure management protocol
> and RADIUS server wants to make sure it that only secure protocols are
> authorized).

Exactly.