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@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf