Hi Dave,
Thanks for your extremly quick response.
See my response below.
-----Original Message-----
From: tsv-dir-bounces(_at_)ietf(_dot_)org
[mailto:tsv-dir-bounces(_at_)ietf(_dot_)org] On Behalf Of Dave Nelson
Sent: 06 May, 2009 16:56
To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'TSV Dir';
kaushik_narayan(_at_)yahoo(_dot_)com
Cc: ietf(_at_)ietf(_dot_)org; isms(_at_)ietf(_dot_)org
Subject: Re: [tsv-dir] Transport directorate review
ofdraft-ietf-isms-radius-usage-06
Hannes Tschofenig writes...
Subject: Transport directorate review of
draft-ietf-isms-radius-usage-06
I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents.
Thanks for your review and your comments.
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 +---------------+
Another reviewer indicated that a diagram would have been
helpful to him, so we should probably consider adding one.
OK.
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.
My reading of RFC 5090 was that is adds another authentication
method to RADIUS. I guess I'm missing the part where it
changes the basic RADIUS model. :-)
It adds an authentication mechanism as well. The important part, however, is
that it uses RADIUS for an application layer protocol (HTTP and SIP) rather
than for network access. You are essentially doing the same (just for a
different protocol).
Section 1.2 provides an overview of RADIUS. However, I don't
think it
is appropriate to use RFC 2119 language in that section.
Hmmm. I fear getting the reverse comment if we de-capitalize
the keywords.
Might be.
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.
We may end up using a two-step process involving "Authorize
Only" when we take up the VACM-related work. There is no
reason to mention such a mechanism in the scope of this
document, however.
OK. I don't know the background of your work.
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?
The reason is that "hint" attributes are traditionally optional.
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.
Another reviewer mentioned this same point. We could consider
making this a MUST, without unduly impacting interoperability
with existing RADIUS servers as servers are always free to
ignore such hints.
I don't think this will impact interoperability in any way. If you don't
want to use a MUST then you might want to say what happens if these
attributes are not provided and how the AAA server should react.
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):
"
I'm not sure that a keyword is required here, but if one were
to be required is would be MUST.
When the AAA server made the decision that the authentication and
authorization step was success then wouldn't you send these attributes.
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.
I'm following the precedent of RFC 3580 which defines RADIUS
usage for Layer
2 access control (IEEE 801.1X).
We should put these things in the RADIUS design guidelines on what one would
write into these tables. The current table is incomplete as the RADIUS RFC
puts more attributes in there.
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.
Well, there was no discussion in the ISMS WG that accounting
was an operator requirement. I agree there is a case to be
made for it, but in some sense the work of ISMS is in response
to operator's perceptions of deployment impediments with
SNMPv3. We are out to alleviate those impediments.
OK.
If you look at
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-autho
ri 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-autho
ri 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.
The ISMS WG saw no use case for SNMP.
OK.
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.
Session timeouts are supported in the document.
http://www.ietf.org/internet-drafts/draft-ietf-radext-management-autho
ri 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?
Yes, because they are not needed to solve the problem this
draft addresses.
If the currently proposed re-chartering is approved in the
ISMS WG, then one of these, the Management-Policy-Id, will
likely be used to provision an extension to VACM. The last
one is defined to apply to CLI only, so would never be of
interest in SNMP work.
OK.
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-autho
ri 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?
Right. The ISMS WG was formed to address impediments
operators perceived in the "ease of deployment" of SNMPv3.
The goals were to apply mechanisms and infrastructure that the
operators were already using. This drove choices such as SSH
and RADIUS.
OK.
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.
Could you elaborate? We all know that RADIUS has outdated
security mechanisms, but what specifically about usage with
SSH causes additional concerns?
I could imagin that administrators might not want their username / password
to travel over the the AAA broker infrastructure when they are also allowed
to configure network equipment. So, the security risk of exposure of
credentials is more than just fraud.
No problem with SSH as such.
Maybe I see it more dramatic as it is.
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.
We had something longer, but it was shortened to the current
form to resolve WGLC comments. :-)
Sorry. I know what you mean; I had many comments from Glen already :-)
Another commented asked
for an explanation of why this recommendation was being made,
and the following answer was given.
It is useful because the Message-Authenticator Attribute is
the best available mechanism in RADIUS as it stands today to
provide tamper-evident integrity protection of the service
provisioning attributes in an Access-Accept packet. It is
slightly less important for Access-Request packets, although
it may be desirable to protect any "hint" attributes contained
in those messages. This protection mitigates the fact that
RADIUS messages are not encrypted and attributes could be
added, deleted or modified by an adversary in a position to
intercept the packet.
I know the Message-Authenticator.
This is all pretty standard RADIUS Security Considerations
material,
That's true.
and could be shortened to a brief explanation for
inclusion in this draft.
I just thought that the text from the RADIUS Design Guidelines draft was
quite good. With the background on all the key management work I thought it
would be useful to mention the confidentiality protection.
(I deleted the sentence that said that RADIUS security is quite bad.)
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.
"
Well, yes. I'm not sure how far to go here. The idea was to
use the operators' existing RADIUS infrastructure. Yes, new
firmware will be required in the NASes, but the attributes
used in this document can be added to the data dictionary of a
data dictionary driven RADIUS sever without any change to the
server software.
I think IPsec usage is fine if operators care about the security of their
credentials.
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.
I don't think that would serve the goals of the ISMS WG.
Most likely not.
IPsec on the other hand can be used without any problems
(and is used
today a lot for protection of RADIUS).
Yes, but is it used in the deployment scenarios this work is targeting?
You tell me.
Whatever you write in this document the operators will use anyway whatever
they want.
Ciao
Hannes
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf