Re: [Isms] WGLC: draft-ietf-isms-radius-usage-02

["David B. Nelson" <dnelson at elbrysnetworks.com>]

David Harrington writes...

> I have reviewed this document. Comments below.

Thank you for your thorough review.  I will respond to those issues that are
easily resolved and highlight those which require further thought or
discussion.

> I found the document a little hard to read because background info on
> RADIUS, info on the management-policy-id related attributes, and the
> mapping to SNMP are all mushed together.

This is something that will require further thought.  The authors added the
introductory material in response to your comments on a previous version.  A
plan to more clearly delineate the various elements will require some time
spent in re-reading the material with an eye toward that objective.

> In discussing the mapping to SNMP, PLEASE assume that the
> management-policy-id has already been accepted by the IETF.

Sure.

> That means a lot of the phrases like "RADIUS servers compliant to this
> specification" can just be reduced to "RADIUS servers".

I think you misunderstand the intent of that phrase.  It has nothing to do
with the status of the document (draft or published RFC) and everything to
do with the fact that there is no monolithic RADIUS Standard.  There is the
base RADIUS protocol and there are number of optional extensions, supporting
specific applications.

> So, I recommend the document have sections 1) introduction to standard
> RADIUS, 2) introduction to the management-policy-id and related
> attributes, and THEN discuss the mapping to SNMP (Actually, I would be
> fine with having the first two combined or possibly eliminated).

Well, as to the possibility of eliminating the introductory material, it's
largely there at your request.  :-)

> I think this document should be written as one of multiple mapping
> documents for the management-policy-id and related attributes, and it
> should be expected that a mapping document will be done at some point
> for Netconf, the CLI, and potentially other interfaces. 

Hmmm.  That sounds like scope-creep.  I agree that we should avoid creating
any gratuitous SNMP-specific dependencies, but this document is about RADIUS
and SNMP, not about RADIUS and anything else.  Right?

> 1. I recommend moving the "Requirements language" text into a section,
> possibly under Introduction.

I'll need to review the draft to identify this text, but the suggestion
sounds very reasonable.

> section 1.1 - we don't have modules in ISMS, we have models and
> subsystems.

I always think I've got rid of the last of those, but I probably introduce
new ones at the same time as eliminating old ones.  :-)  We'll take care of
this.

> section 1.2 says "An Access-Reject message indicates unsuccessful
> authentication." Does it also indicate an unsuccessful authorization?

Yes.

> section 2 says
>    "Service authorization allows a RADIUS server to authorize an
>     authenticated principal to use SNMP over a specific secure
>     Transport Model.
> I think that is incorrect. The attributes we intend to use here
> authorize the use of a service for Framed-Management, the
> Framed-Management-Protocol to use (SNMP), a Management-Policy-ID (such
> as "Operator"), and a level of Transport-Protection.

Yes.  That's a mouthful (run-on sentence) but that's really what's meant.

> section 2 discusses PAM; how do RADIUS servers in a Windows
> environment do this?

PAM is an interface between an end-user data service (e.g. SSH) and an
authentication service (e.g. RADIUS Client).  RADIUS Servers do not come
into the picture.  PAM is common in Unix environments.  I don't know what
the equivalent is in a Windows environment.

> s/rely of/rely on/

OK.

> section 2.1
> "Specific attributes for use with SNMP Transport Models are
> recommended in this document." I don't think this document should be
> used to make recommendations of specific RADIUS attributes. This
> document should simply be about how to use the management-related
> attributes that are defined, in an SNMP environment.

Huh?  You want this document to describe how to use RADIUS for
authentication and authorization of SNMP access without mentioning specific
RADIUS attributes?  I know that SNMP documentation and architecture is big
on abstraction, models, and such.  RADIUS documentation doesn't go in for
that sort of thing, for better or worse.  I wouldn't know where to begin...

> s/"RADIUS servers, compliant to this specification, MAY use RADIUS
> hint attributes, as described herein, to inform the decision whether 
> to accept or reject the authentication request."/
>   "RADIUS servers MAY use RADIUS hint attributes to inform the
> decision whether to accept or reject the authentication request."/

OK.  You don't like my overly-formal language.  I can live with that.

> (but isn't the hint really part of an authorization request rather
> than an authentication request?

You can't really separate the two in RADIUS, as much as one might like to.
I know this has been an issue in the ISMS work, but RADIUS is a legacy
protocol and "it is what it is".

> I might be able to authenticate who I am, but still not get approval
> to access the SNMP service.")

That's true.  In that case one of two things would happen.  The RADIUS
Server would return an Access-Accept message provisioning a default service
for your profile that you are authorized to use, or more likely the RADIUS
Server would return an Access-Reject message, because you are not authorized
to use the service you are apparently requesting. 

> section 2.2 eliminate the sentence
> "   Specific attributes for use with SNMP Transport Models are
>    recommended in this document."

This gets back to my previous question.  Are you effectively asking the
authors to create an abstract "model" of how RADIUS might interact with
SNMP?  I don't think that's what we have been tasked to produce.  If that's
not what you're asking of us, what is your concern with specificity? 

> "   The following RADIUS attributes MAY be optionally used, to
> authorize use of SNMP over the default UDP transport protocol (no
> privacy):"
> What transport model calls RADIUS to authenticate a UDP session? This
> is news to me.

Hmmm.  That looks wrong.  I forget where that came from, but it will be
removed.
 
> "   The following RADIUS attributes are used to limit the extent of a
>    secure transport session carrying SNMP traffic, in conjunction with
>    an SNMP Transport Model:
> 
>    1.  Session-Timeout
>    2.  Inactivity-Timeout."
> What transport model does this?

Well, I'm not sure any of them do...  more like they should.  I think this
needs some discussion.

> I think this is between RADIUS and the transport protocol that is
> using RADIUS, such as SSH.

Quite possibly.

> I don't think SNMP has anything to do with this, and there is no 
> place in the ISMS architecture to specify these values.

There may not be a place in the ISMS architecture.  However, RADIUS has a
long history of provisioning limits on the services that it authorizes, so
it seemed natural to continue this practice with SNMP.

> I am not sure they should be discussed in this document.

If not here, then where?

> Is this Inactivity-Timeout related to the Idle-Timeout mentioned
> later?

Yes.

> section 2.4. I think the authorization attributes provided by RADIUS
> should probably be captured as part of the LCD, as part of
> transport-specific information.

I don't understand.

> section 3 should be part of the introduction to RADIUS and the
> management related attributes. It seems out of place here.

Well, in RADIUS documents there is always a Table of Attributes near the end
of the document, just before such sections as the Security Considerations.
In case it's not already apparent, the authors are following RADIUS document
style and not SNMP document style.

> section 5
> s/Threats and security issues for
>    this application are described in [RFC3579] and [RFC3580]; "
> /Threats and security issues for
>    RADIUS are described in [RFC3579] and [RFC3580];/

OK.
 
> Paragraph three discusses selecting SNMPv1 and SNMPv2c. I think the
> discussion of using RADIUS with these needs further discussion.

OK.  I'm sure I got this text from some posting on the ISMS list, but I'm
not sure it's correct or complete.

> Currently, SNMPv1 can be used with an SSH tunnel, with no transport
> model to provide a binding; we might develop a transport model with a
> binding. The RADIUS attributes for management, however, may not allow
> us to choose which transport model or even which transport protocol,
> and under those conditions, I don't know what we have for security
> with an SNMPv1 or SNMPv2c (or SNMPv3) message, since we may have no
> transport model to provide a mapping between the transport layer
> credentials and the SNMP-specific securityModel/Name/Level.
> 
> The "this may not be expected" would probably be better phrased as
> "the authenticated identity used for securityName will not be the
> identity authenticated by RADIUS".

OK.


_______________________________________________
Isms mailing list
Isms at ietf.org
https://www.ietf.org/mailman/listinfo/isms