ietf
[Top] [All Lists]

Transport directorate review of draft-ietf-isms-radius-usage-06

2009-05-06 07:39:16
I've reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the
document's authors for their information and to allow them to address
any issues raised. The authors should consider this review together with
any other last-call comments they receive. Please always CC
tsv-dir(_at_)ietf(_dot_)org if you reply to or forward this review.

I understand the purpose of the document and I am fine with the content.
I only have some minor comments/questions. 

Since I am familiar with the work on RADIUS I had already a clue about
the direction the document when I read the title. Still, a diagram would
help with the basic idea. In some sense your document is based on a
fairly obvious idea, namely to use the RADIUS backend infrastructure to
relay authentication and authorization for SSH. So, a figure like this
one could help: 

                                      +--------+
                                      |RADIUS  |
                                      |Server  |
                                      +--------+
                                          ^
                                 RADIUS + |  Back-End
          Management-Transport-Protection |  Protocol
               Framed-Management-Protocol |  Support
                                          |
                                          v
  +---------+                      +---------------+
  | Admin's |  SNMP                |RADIUS Client /|
  | Device  |<-------------------->|Network Device |
  +---------+  SSH                 +---------------+


Regarding the following statement:

   The RADIUS protocol [RFC2865] provides authentication and
   authorization services for network access devices, usually referred
   to as a Network Access Server (NAS).

This is not the only usage of RADIUS. See, for example,
http://www.ietf.org/rfc/rfc5090.txt

The interesting thing is that you are defining a RADIUS usage that is
conceptually extremely close to RFC 5090. 

Section 1.2 provides an overview of RADIUS. However, I don't think it is
appropriate to use RFC 2119 language in that section. 


You write: 

   RADIUS almost always involves user authentication as
   prerequisite to authorization, and there is a user authentication
   phase for each of these two use cases.

Since you mention authorize only later you could refer to this aspect as
well. 
The usage of "Authorize Only" http://www.ietf.org/rfc/rfc3576.txt allows
you  todo authorization without running the authentication exchange even
though you bind the authorization step to a previously done
authentication exchange.  


  The following RADIUS attributes SHOULD be used, as hint attributes
   included in the Access-Request message to signal use of SNMP over a
   secure transport (i.e. authPriv) to the RADIUS server:

Why don't you use a MUST here? In the previous section you describe how
important it is for the AAA server to figure this information out and
here you  have a SHOULD and do not explain what happens otherwise if
this information is  not sent. 

   The following RADIUS attributes are used in an Access-Accept message
   to provision SNMP over a secure transport which provides both
   integrity and confidentiality (i.e. authPriv):

I suspect that this should read as 
"
   The following RADIUS attributes MUST be used in an Access-Accept
message
   to provision SNMP over a secure transport which provides both
   integrity and confidentiality (i.e. SNMP authPriv):
"
In Table 2 I was only expecting to see the newly introduced RADIUS
attributes  rather than the attributes that come via the base RADIUS
RFC. I wouldn't do that. 

You excluded accounting from the document and I was wondering whether
logging isn't a useful feature (or event required) to ensure
accountability when it comes to the management of network equipment. If
you look at
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori
zation-06.txt then you will notice that they allow accounting messages
to carry these new attributes. Btw, the authors of
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori
zation-06.txt also allow CoA to be used even though I cannot really say
whether this is useful in the context of a SNMP. Withdrawing access
right for a person that is logged into an administrative interface, as
it can be done with CoA, does not sound too far fetched to me. Another
example is the need for re-authentication after a certain time period. 


http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori
zation-06.txt defines 4 new RADIUS attributes, namely
- Framed-Management-Protocol
- Management-Transport-Protection
- Management-Policy-Id
- Management-Privilege-Level

You don't make use of the last two. Is there a specific reason? 
I would have just copied the Table of Attributes from
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori
zation-06.txt and maybe you would have to add a little bit of text
indicating whether these two additional AVPs are somehow in relationship
with SNMP usage.


In your document you only focus on RADIUS whereas the document that
defines the attributes, namely
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authori
zation-06.txt, also defines them for Diameter. Any reason why you did
not extend your description also to Diameter? Maybe because Diameter is
not used in your envisioned usage domain or so? 



Regarding the security considerations: The interworking between RADIUS
and SSH for authentication and authorization does not really allow
"high-quality" authentication mechanisms to be used. In the document
itself you state that mostly username/password is going to be utilized
and hence I believe that the solution is not secure outside a single
adminstrative domain. Hence, I would spell this out in the security
consideration section instead of referring to AAA roaming, particularly
RFC 2607. 

Regarding the usage of the Message authentication in RADIUS. I suggest
to copy-and-paste the following paragraph from 
http://tools.ietf.org/html/draft-ietf-radext-design-07
and modify it slightly: 

"
   Message authentication in RADIUS is provided largely via the Message-
   Authenticator attribute.  See [RFC3579] Section 3.2, and also
   [RFC5080] 2.2.2. Unfortunately, the Message-Authenticator attribute
   does not provide confidentiality protection. 

   To avoid eavesdropping of RADIUS message exchanges a secure
communications protocol, such as
   IPsec or TLS (with RadSec
http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-04.txt)
MUST be used.  See [RFC3579] Section 4, and [RFC3580] Section 5 for a
more
   in-depth explanation of these issues.
"

If you add RadSec as a normative references your document will
unfortunately be blocked a little bit (until RadSec is completed) and
you will have to repeat the IETF Last Call since RadSec will have to be
indicated as a DownRef in the LC. 

IPsec on the other hand can be used without any problems (and is used
today a lot for protection of RADIUS). 
Editorial:

FROM:

SSH server implementations often use the Pluggable
   Authentication Modules (PAM)
   [http://www.opengroup.org/rfc/rfc86.0.html] interface provided by
   operating systems such as Linux and Solaris to integrate with
   password based network authentication mechanisms such as RADIUS,
   TACACS+, Kerberos, etc.

TO:

SSH server implementations often use the Pluggable
   Authentication Modules (PAM) [ref1] interface provided by
   operating systems, such as Linux and Solaris, to integrate with
   password based network authentication mechanisms, such as RADIUS,
   TACACS+, and Kerberos.

[ref1] http://www.opengroup.org/rfc/rfc86.0.html

FROM:

 The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines a
   mechanism for providing transport layer security for SNMP, allowing
   protocols such as SSH and TLS to be used to secure SNMP
   communication.

TO:

 The Transport Subsystem for SNMP [I-D.ietf-isms-tmsm] defines a
   mechanism for providing transport layer security for SNMP, allowing
   protocols, such as SSH and TLS, to be used to secure SNMP
   communication.

FROM:

   The Secure Shell protocol provides a secure transport channel with
   support for channel authentication via local accounts and integration
   with various external authentication and authorization services such
   as RADIUS, Kerberos, etc.

TO:

   The Secure Shell protocol provides a secure transport channel with
   support for channel authentication via local accounts and integration
   with various external authentication and authorization systems, such
   as RADIUS, and Kerberos.

FROM:

   1.  Service-Type with a value of Framed-Management.
   2.  Framed-Management-Protocol with a value of SNMP.
   3.  Management-Transport-Protection with a value of Integrity-
       Confidentiality-Protection.

TO:

   1.  Service-Type with a value of TBA-x for "Framed-Management.
   2.  Framed-Management-Protocol with a value of (1) for "SNMP".
   3.  Management-Transport-Protection with a value of (3) for
       "Integrity-Confidentiality-Protection".

The Service-Type value for TBA-x is registered via
draft-ietf-radext-management-authorization. 

FROM:

   The following RADIUS attributes MAY be optionally used, to authorize
   use of SNMP without protection (i.e. authNoPriv):

TO:

   The following RADIUS attributes MAY be optionally used, to authorize
   use of SNMP without integrity and confidentiality protection (i.e., 
   equivalent to the SNMP authNoPriv access).


FROM:

   1.  Service-Type with a value of Framed-Management.
   2.  Framed-Management-Protocol with a value of SNMP.
   3.  Management-Transport-Protection with a value of No-Protection.


TO:

   1.  Service-Type with a value of TBA-x for "Framed-Management.
   2.  Framed-Management-Protocol with a value of (1) for "SNMP".
   3.  Management-Transport-Protection with a value of (1) for
"No-Protection".

Ciao
Hannes
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>