Subject: [Isms] WGLC: radius-usage-04

From: "David Harrington" <[email-masked]>
Date: Mon, 5 Jan 2009 16:48:22 -0500

Hi,

A few comments.

1) in section 1.4, we probably should not be discussing the TSM
security model. The radius support is in the transport model, and a
radius-supported transport model should work with any security model.
How a security model is selected and how it sets the securityName is
specific to the security model, not to radius-usage.

2) In section 2, it state sthat service authroization [authorizes]
SNMP over a specific Transport Model. I believe that has been changed
in radius-mgmt-auth to be a specific transport protection.

3) In section 2.3, would it be simpler to introduce the attributes
first so we can eliminate all the redundant "refre to ... from the
perspective ..." notes?

Would it be simpler to elimiate the "from the perspective ... th euser
is requesting ..." and simply start each example with "To request ...
set the attributes with the values ..."

s/to to/to/

4) do we really need section 2.4, that says "here is stuff we don't
discuss here"?

5) section 5
s/module/model/g

Paragraph 3 and 4 can be made more succinct:
"If the SNMPv1 or SNMPv2c Security Model is used, then securityname
comes from the community name, as per RFC3584. If the User-based
Security Model is selected, then securityName is determined using USM.
This may not be what is expected when using an SNMP secure Transport
Model with an external authentication service, such as RADIUS.

Combining a secure transport with RADIUS authentication/authorization,
and the SNMPv1 or SNMPv2c or USM security models is NOT RECOMMENDED.
See the coexistence section of [TMSM]."

s/in tandem with/to supplement/
s/for any reason//

s/as defined in [rfc3579]/as defined in "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible Authentication Protocol
(EAP) [RFC3579]/
Is this Informative or Normative? To follow the advice given here, one
would need to know rfc3579.

Hope this helps,

David Harrington
[email-masked]
[email-masked]
[email-masked]

_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: kaushik <[email-masked]>
Date: Tue, 06 Jan 2009 09:05:51 -0800

Hi David,

Thanks for your comments.

Please find my reply inline.

> specific to the security model, not to radius-usage.

<Kaushik>

Section 1.4 is introductory text to provide the broad context for transport
based security for SNMP, it references the existing work being done in the
WG (transport subsystem, transport security model, ssh transport model).

The securityName text was to indicate the flow of RADIUS userName attribute
to & from the RADIUS layer up to the security model.

</Kaushik>

> in radius-mgmt-auth to be a specific transport protection.

<Kaushik>

You are right. That text needs to be updated.

</Kaushik>

> 4) do we really need section 2.4, that says "here is stuff we don't

<Kaushik>

I think it is useful to indicate that user authz is out of scope since the
RADIUS mgmt authz has mechanisms that provide both service and user authz
and this specification describes usage of service authorization.

Regards,
 kaushik

</Kaushik>

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 6 Jan 2009 14:21:36 -0500

Dave Harrington writes...

> The radius support is in the transport model, and a

*Any* security model?  Surely not the User-based Security Model (USM).  I
think it is reasonable to assert that RADIUS SHOULD work with the Transport
Subsystem and the Transport Security Model.

> How a security model is selected and how it sets the securityName
> is specific to the security model, not to radius-usage.

Yes, but as I indicated in another reply, the assumptions around mapping of
authenticated user identities for the purpose of service authorization are
of consequence to the RADIUS community.

> 2) In section 2, it states that service authorization [authorizes]

So, we could change:

   Service authorization allows a RADIUS server to authorize an
   authenticated principal to use SNMP over a specific secure Transport
   Model.

to read:

   Service authorization allows a RADIUS server to authorize an
   authenticated principal to use SNMP over a specific level of 
   transport protection.

> first so we can eliminate all the redundant "refre to ... from the

Well, Section 2.* is a general operational overview discussion.  Editorially
speaking, it's convenient to discuss the general concepts before the gory
details.  Having said that, I agree that the formal forward reference "Refer
to [I-D.ietf-radext-management-authorization] for a detailed description of
these attributes." could simply be eliminated.

> Would it be simpler to eliminate the "from the perspective ... the user

Yes, we could do something like that, with the caveat that there are request
and response semantics that need to be listed separately.

> s/to to/to/

I don't see this immediately, but I'll search for it.

> s/module/model/g

:-)

> Model with an external authentication service, such as RADIUS.

OK.

> See the coexistence section of [TMSM]."

OK.

> s/in tandem with/to supplement/

OK.

> Dial In User Service) Support For Extensible Authentication Protocol

Umm.  This may be obviated by another comment from Jeff Hutzelman, but I've
seen other RFCs that don't preface the reference designator {RFCnnnn] with
the fully spelled out document name.  Of course, this is a style issue, more
in the domain of the RFC Editor.

> would need to know rfc3579.

We can follow the suggestions that Jeff offers on Normative vs. Informative.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 6 Jan 2009 13:32:34 -0500

Kaushik writes...

> The securityName text was to indicate the flow of RADIUS 
> username attribute to & from the RADIUS layer up to the
> security model.

Yes, there are certain expectations within the RADIUS community about how
User-Name attributes are used in authentication, authorization and service
provisioning.  Generally speaking, session authorization is bound to the
user's identity.  This may or may not be the case with SNMP, because of the
potential for mapping between the RADIUS User-Name and the SNMP
securityName.  I think it's important to call attention that feature.

The authors assume that this document has two (possibly overlapping)
audiences: the RADIUS community and the SNMP community.  The reason for the
introductory text is to expose each community to enough of the context
commonly held by the other community so that understanding is universal.

> I think it is useful to indicate that user authz is out of scope
> since the RADIUS mgmt authz has mechanisms that provide both service
> and user authz and this specification describes usage of service 
> authorization.

This is another attempt at creating shared context.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 06 Jan 2009 16:08:40 -0500

--On Tuesday, January 06, 2009 02:21:36 PM -0500 "David B. Nelson" 
<[email-masked]> wrote:

> think it is reasonable to assert that RADIUS SHOULD work with the
> Transport Subsystem and the Transport Security Model.

Yes, _any_ security model.  I should be able to use SSH transport with USM, 
and something reasonable should happen.  Particularly, with respect to 
RADIUS, I think session authorization should happen in the transport 
regardless of what SNMP security model is used.

> Umm.  This may be obviated by another comment from Jeff Hutzelman, but
> I've seen other RFCs that don't preface the reference designator
> {RFCnnnn] with the fully spelled out document name.  Of course, this is a
> style issue, more in the domain of the RFC Editor.

The style question here is one of whether reference designators are used as 
grammatical objects.  In traditional print media, references are designated 
by a superscripted letter, number, or symbol, and are _never_ grammatical 
objects.  Some people believe we should follow this rule in our documents, 
even though the designators are less unobtrusive; others believe it is fine 
to use them directly as grammatical objects.  Personally I don't mind, as 
long as we are consistent.  AFAIK the RFC-Editor doesn't have a preference 
for one style over the other; I've seen published documents using both.

-- Jeff

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 6 Jan 2009 16:34:32 -0500

> Yes, _any_ security model.  I should be able to use SSH transport
> with USM, and something reasonable should happen.  Particularly,
> with respect to RADIUS, I think session authorization should happen
> in the transport regardless of what SNMP security model is used.

Well, Jeff, unfortunately your "should" seems to me an expression of desired
behavior as opposed to an expression of technical feasibility (as in my
retirement nest egg "should" support me in my golden years).  :-)

In point of fact, I see no reasonable way to use RADIUS with USM, based on
the architecture that we've agreed to in ISMS.  Of course, all things are
possible in software, so with a different architecture something might work
out.  The specific issues with USM are that it has inherent dependencies on
the credentials being stored in the local configuration data-store and it
conflates authentication with confidentiality in a way that RADIUS would be
hard pressed to support.

If you see a way clear of these impediments, I'd be curious to hear of it.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Jan 2009 23:52:47 +0100

> conflates authentication with confidentiality in a way that RADIUS would be

I believe Jeff is talking about the scenario USM over SSH where RADIUS
would do the SSH session authentication and not really care about any
of the USM specifics.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 6 Jan 2009 22:02:51 -0500

Juergen Schoenwaelder writes...

> I believe Jeff is talking about the scenario USM over SSH where 
> RADIUS would do the SSH session authentication and not really 
> care about any of the USM specifics.

I'd have to think a bit about what this means.

In the case of the USM, the packet-by-packet authentication is performed in
the Security Model using pre-shared keys, tied to a locally stored username.

In the case of TM with TSM, the SSHTM provides the authentication of the
packet stream, because it's a protected transport session.  We have
specified a way associate the identity known to the TM and the TSM by
mapping and caching.

If we use SSH with USM, there is certainly a protected transport session,
but it's in no way tied to the Security Model (USM), and there is certainly
no tie in to any Access Control Model that might be in use.  I'm having
difficulty understanding now the totally unrelated identities, the one tied
to the SSH session and the one tied to the USM, provided a reasonable and
secure solution.  Perhaps I simply haven't thought about in enough, but I
just don't get it.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Jan 2009 08:49:31 +0100

> secure solution.  Perhaps I simply haven't thought about in enough, but I

I am not discussing here to what extend this is reasonable/desirable,
I understand Jeff's comment from an architectural point of view. This
combination is more like an SSH tunnel and RADIUS in this case is used
to determine whether the tunnel can be established.

I think we already agreed that RADIUS for now does not tie into SNMP
access control since doing so is outside of our charter. SNMP's access
control decision is based on identity determined by the SNMP security
model used to handle the message.

/js

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 7 Jan 2009 08:42:02 -0500

> I am not discussing here to what extend this is reasonable/desirable...

Well, OK.  I guess I won't waste very much time discussing desirable but
unreasonable things.  :-)

> I understand Jeff's comment from an architectural point of view.

As do I.  From an architectural point of view what Jeff suggests ought to be
capable of working, in a reasonable and secure fashion.  I think perhaps we
disagree on what constitutes reasonable and secure, and whether the
architecture we've devised here in ISMS works (well) in that particular
configuration.

> This combination is more like an SSH tunnel and RADIUS in this case
> is used to determine whether the tunnel can be established.

Yes.  I agree with that.  Does that automatically imply that the user at the
end of the tunnel is authorized to use SNMP?  Maybe.  If the SNMP engine is
bound so tightly to SSH that the tunnel is the only way to access SNMP, you
might accomplish that goal.  Otherwise, there are "two sets of books" used
for authentication -- one in the RADIUS server and a second one in USM's
local configuration data-store.  They could be different, or they could
appear to be similar, e.g. "dave" in RADIUS might be a different persona
than "dave" in USM.

In addition to that, you need to account for the provisioning of the shared
keys, unless you are using noAuth noPriv, in which case you are using the
"null security" of USM, and it's a degenerate, non-interesting case.

> access control since doing so is outside of our charter.

We did agree to that.  Some of us strongly argued that it was a silly thing
to agree to, but were told that it was necessary to focus on one thing at a
time, and that we would likely cycle back to that work via a re-charter once
the base workload was completed.  I have always said, and repeat here, that
authentication and confidentiality are not much good without (granular)
authorization, i.e. access control.  While it's formally out of scope, the
problem hasn't gone away.

> SNMP's access control decision is based on identity determined by
> the SNMP security model used to handle the message.

Yes, and if the identity determined by the security models is completely
dissociated from the identity authenticated by the RADIUS server, it's a
very broken architecture, IMO.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 7 Jan 2009 09:13:31 -0500

Hi,

> > no tie in to any Access Control Model that might be in use. 

That is correct, architecturally.
There are two different situations requiring authn and authz. 

> I understand Jeff's comment from an architectural point of view.
This
> to determine whether the tunnel can be established.

The first situation is authz for craeting a asecure transport session,
e.g., instantiating an SSH "snmp" subsystem. SSH can use RADIUS to
perform this, if desired. Or SSH can use some other mechanism to
perform authentication, and some other method to determine whether the
authenticated user is authorized to instantiate the "snmp" subsystem.
I think this is comparable to SSH using AAA to determine whether to
instantiate a shell.

The second situation of authn/z is SNMP-specific. An SNMP security
model performs the authentication and creates a securityName that is
then used for SNMP access control. This is comparable to a UNIX system
determining which files a user can read/write/execute.

These two cases of authn/z might use totally different mechanisms:

If an SNMPv1 message is delivered over SSH, the SNMPv1 message
processing model will select the SNMPv1 security model, and set
securityName based on the community. For SNMPv2c messages, the SNMPv2c
security model will be chosen. If an SNMPv3 message is delivered over
SSH to the SNMPv3 message processing model, and the SNMPv3 security
parameters in the message said SecurityModel=USM, then USM would be
called to authenticate based on the credentials that are stored
locally. USM would set a securityName accordingly. That all should
work just fine.

So, even if RADIUS provides the authn/z services for SSH, the
determination  of the security model is handled by the message
processing model. 

The two cases might be integrated:

If an SNMPv3 message is delivered over SSH to the SNMPv3 message
processing model, and the SNMPv3 security parameters in the message
said SecurityModel=TSM, then TSM would be called. TSM would set a
securityName based on the values of tmStateReference. If the Transport
Model has set the values in tmStateReference based on values received
from SSH, that happen to be based on RADIUS authn/z, that should work
just fine as well.

--
The point is that the Transport Model does not get to make the
decision about which security model is called. Period. The
determination of which security model to use is the job of the message
processing model. 

A transport model should be able to transport any version of SNMP
message (including versions not yet defined, and proprietary message
formats) and deliver that message to the dispatcher (which will send
it to the corresponding message processing model). 

The Coexistence section of TMSM discusses the fact that you should not
make assumptions that securityName will be based on the identity used
by the transport security protocol.

The RADIUS server CAN make assumptions about the authn/z used for
initiating the subsystem (case 1). The RADIUS server should make no
such assumptions about the SNMP-internal authn/authz used for
application access control purposes (case 2). 

> model used to handle the message.
I think the "for now" is important here. 

Our task to this point has been to define how RADIUS can be used for
case 1 - how can RADIUS be used to create a secure transport session
for SNMP when using transport security, such as SSH. (RADIUS Usage for
SNMP Transport Models)

Once we complete that work, we can start to work on defining how
RADIUS can be used to provide authn/z services for case 2. (RADIUS
Usage for SNMP Access Control).

dbh

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 7 Jan 2009 10:29:56 -0500

David Harrington writes...

> e.g., instantiating an SSH "snmp" subsystem.

Yes.

> model performs the authentication and creates a securityName that
> is then used for SNMP access control. This is comparable to a UNIX
> system determining which files a user can read/write/execute.

Well, somewhat comparable.  UNIX also has authentication (login) and uses
the results of that to make access control decisions.  There is an inherent
binding of the authentication to the subsequent authorization(s).

SSH might pass a username to the UNIX shell, but the shell still needs to
perform its own authentication (login) according to locally configured
policy.  The shell *might* trust that the username passed by SSH is the same
persona as that same name found in the local (or remote) authentication
database, if it is so configured.

> determination  of the security model is handled by the message

Umm, yes...  but let's try to remember why we are doing this.  The reason
operators use AAA is that maintaining disparate user databases across
multiple devices is fraught with difficulty.  We need to assume that if
RADIUS is "in play" in a given deployment, that the operator has decided
that the benefits of centralized AAA are valuable, and thus we should not be
introducing use cases in which AAA needs to be supplemented with auxiliary
user identity databases.  That's counterproductive to the effort.

Another way of saying this is that we can ask three questions about any
architectural scenario:

(1) Would it work?

(2) Would any operator be likely to want to use it?

(3) Would it be secure?

I'm attempting to answer Questions (2) and (3).

> determination of which security model to use is the job of the
> message processing model.

Yes, and this gives rise to combinations that pass Question (1) but not
Question (2) and maybe not Question (3).

> The Coexistence section of TMSM discusses the fact that you should
> not make assumptions that securityName will be based on the identity
> used by the transport security protocol.

Which, IMO, is equivalent to saying you shouldn't assume that the system
will be secure.  :-)  I admit that I'm taking a very AAA-centric view here,
but I think that's perfectly reasonable in discussing the RADIUS Usage
draft.

> application access control purposes (case 2).

Right.  That's an issue, however, it's a bit off the point of this
particular thread.  My original post objected to the notion that RADIUS and
SNMP transport-based security (TM/TSM/SSHTM) could be reasonably used in
conjunction with USM.

If I understand you correctly, you are suggesting that SNMP secure
transports (TM/SSHTM) can be used independent of SNMP transport-based
security (TSM).  That's probably correct.  OTOH, we've never spent time
discussing such usages, and I'm still uncomfortable that the may be some
unpleasant surprises in store.

> Our task to this point has been to define how RADIUS can be used
> for case 1 - how can RADIUS be used to create a secure transport 
> session for SNMP when using transport security, such as SSH. 
> (RADIUS Usage for SNMP Transport Models)

When using transport security, but maybe not using the transport security
model?  When you say transport security, you really mean secure transport?

> Usage for SNMP Access Control).

OK, fair enough.

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 7 Jan 2009 13:30:01 -0500

> 4) do we really need section 2.4, that says "here is stuff we don't

Well, I guess this represents a lingering level of distrust (at least on the
part of this author) that the WG will eventually get around to addressing
this important issue.  With the caveat that ISMS anticipates a re-charter
discussion that would bring this issue into scope and that we would expect
to see a companion "RADIUS Usage for SNMP Access Control Models" document,
yes, this section can be removed.

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 7 Jan 2009 13:59:55 -0500

Based on the discussion so far, I'd like to propose the following revisions
to the draft:

Old:

2.  RADIUS Usage for SNMP Transport Models

   There are three ways in which RADIUS may be used by SNMP Transport
   Models.  These include (a) user authentication, (b) service
   authorization and (c) access control authorization.  The first two
   items are discussed in detail in this memo, while the third item is a
   topic of current research, and beyond the scope of this document.
   This document describes the way in which RADIUS attributes and
   messages are applied to the specific application area of SNMP
   Transport Models.

New:

2.  RADIUS Usage for SNMP Transport Models

   There are three ways in which RADIUS may be used by SNMP.  These
   include (a) user authentication, (b) service authorization and
   (c) access control authorization.  User authentication and service
   authorization via RADIUS are undertaken by the Transport Model,
   and are discussed in detail in this memo.   Access control would
   be undertaken by the Message Processing Model and an Access Control
   Model, is a topic of current research, and is beyond the scope of
   this document.  This document describes the way in which RADIUS
   attributes and messages are applied to the specific application 
   area of SNMP Transport Models.

Also in Section 2:

Old:

   Service authorization allows a RADIUS server to authorize an
   authenticated principal to use SNMP over a specific secure Transport
   Model.  This memo describes mechanisms by which such information can
   be requested from a RADIUS server and enforced within the NAS.  The
   SNMP architecture, as described in RFC 3411 [RFC3411], does not make
   a distinction between user authentication and service authorization.
   In the case of existing, deployed security models, such as the User-
   based Security Model (USM), this distinction is not significant.  For
   the SNMP Transport Models and the SNMP Transport Security Model
   (TSM), this distinction is relevant and important.

New:

   Service authorization allows a RADIUS server to authorize an
   authenticated principal to use SNMP over a specific secure Transport
   Model.  This memo describes mechanisms by which such information can
   be requested from a RADIUS server and enforced within the NAS.  The
   SNMP architecture, as described in RFC 3411 [RFC3411], does not make
   a distinction between user authentication and service authorization.
   In the case of existing, deployed security models, such as the User-
   based Security Model (USM), this distinction is not significant.  For
   SNMP Transport Models, this distinction is relevant and important.

Remove the following paragraph:

   Data object access control authorization in SNMP is handled by the
   Access Control Subsystem (ACS), instantiated as various Access
   Control Models.  The SNMP architecture, as described in RFC 3411
   [RFC3411], explicitly mandates the separation of authentication and
   authorization operations in order to retain modularity of the SNMP
   system.  The Abstract Service Interface (ASI) of the ACS uses method-
   independent parameters, including securityName, to determine access
   control rights.  A detailed description of how an Access Control
   Model (ACM) might utilize the services of a RADIUS client to obtain
   access control policy information is a topic of current research, and
   beyond the scope of this document.

In Section 2.2:

Old:

   A NAS that is compliant to this specification, MUST treat any RADIUS
   Access-Accept message that provisions a transport protocol (e.g.
   SSH) that cannot be provided, and/or application service (e.g.  SNMP)
   that cannot be provided over that transport, as if an Access-Reject
   message had been received instead.  The RADIUS Service-Type attribute
   is the primary indicator of the service being provisioned, although
   other attributes may also convey service provisioning information.
   Specific attributes for use with SNMP Transport Models are
   recommended in this document.

New:

   A NAS that is compliant to this specification, MUST treat any RADIUS
   Access-Accept message that provisions a level of transport protection
   (e.g. SSH) that cannot be provided, and/or application service (e.g.
   SNMP) that cannot be provided over that transport, as if an Access-
   Reject message had been received instead.  The RADIUS Service-Type 
   Attribute is the primary indicator of the service being provisioned,
   although other attributes may also convey service provisioning 
   information.

In Section 2.3:

Old:

   RADIUS servers compliant to this specification SHOULD use RADIUS
   service provisioning attributes, as described herein, to specify SNMP
   access over a secure transport protocol.  Such RADIUS servers MAY use
   RADIUS hint attributes included in the Access-Request message, as
   described herein, in determining what, if any, service to provision.

New:

   RADIUS servers compliant to this specification SHOULD use RADIUS
   service provisioning attributes, as described herein, to specify SNMP
   access over a secure transport.  Such RADIUS servers MAY use RADIUS
   hint attributes included in the Access-Request message, as described
   herein, in determining what, if any, service to provision.

Old:

   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:

   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.

   Refer to [I-D.ietf-radext-management-authorization] for a detailed
   description of these attributes.  From the perspective of the RADIUS
   Server, these attribute and value pairs indicate that the user is
   requesting to use SNMP over an SNMP secure Transport Model.

New:

   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:

   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.

Old:

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

   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.

Old:

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

   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.

   Refer to [I-D.ietf-radext-management-authorization] for a detailed
   description of this attribute.  From the perspective of the NAS, this
   attribute and value pair indicates that the user is authorized to use
   SNMP without a protected transport.

New:

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

   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.

Old:

   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.

   Refer to [RFC2865] for a detailed description of these attributes.
   From the perspective of the NAS, these attributes indicate session
   timeouts to be applied to the secure transport sessions.  The
   Session-Timeout Attribute indicates the maximum number of seconds
   that a session may exist before it is unconditionally disconnected.
   The Inactivity-Timeout Attribute indicates the maximum number of
   seconds that a transport session may exist without any protocol
   activity (messages sent or received) before the session is
   disconnected.  These timeouts are enforced by the NAS.

New:

   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.

   Refer to [RFC2865] for a detailed description of these attributes.
   The Session-Timeout Attribute indicates the maximum number of seconds
   that a session may exist before it is unconditionally disconnected.
   The Inactivity-Timeout Attribute indicates the maximum number of
   seconds that a transport session may exist without any protocol
   activity (messages sent or received) before the session is
   disconnected.  These timeouts are enforced by the NAS.

Remove the following section:

2.4.  SNMP Access Control Authorization

   [I-D.ietf-radext-management-authorization] describes a RADIUS
   attribute that can be used for SNMP access control authorization,
   however, the details of how an SNMP Access Control Model, such as the
   View-based Access Control Model (VACM) [RFC3415], might utilize
   RADIUS authorization are a topic of current research, and beyond the
   scope of this document.

In Section 5:

Old:

   If the SNMP Message Processing Module selects the SNMPv1 or SNMPv2c
   Security Model as the security model to use (because the message is
   SNMPv1 or SNMPv2), then securityName comes from the community name,
   as per RFC3584.  This may not be what is expected when using an SNMP
   secure Transport Model.  It is NOT RECOMMENDED that a combination of
   a secure transport, RADIUS authentication/authorization, and the
   SNMPv1 and/or SNMPv2c community models be used together, as it
   necessitates the opening of an insecure access path within the Access
   Control Subsystem.

   If the SNMP User-based Security Model is selected (because the SNMPv3
   message contains a msgSecurityModel=USM), then securityName is
   determined using USM (after performing USM authentication).  This may
   not be what is expected when using an SNMP secure Transport Model
   with an external authentication service, such as RADIUS.  USM entries
   for noAuthNoPriv access would allow messages utilizing USM to bypass
   the secure transport.

New:

   If the SNMPv1 or SNMPv2c Security Model is used, then securityname
   comes from the community name, as per RFC3584. If the User-based 
   Security Model is selected, then securityName is determined using
   USM.  This may not be what is expected when using an SNMP secure
   Transport Model with an external authentication service, such as
   RADIUS.

(A specific section number reference would be nice here, too.)

Old:

   There are good reasons to provision USM access in tandem with AAA-
   based access, however.

New:

   There are good reasons to provision USM access to supplement AAA-
   based access, however.

Old:

   The Message-Authenticator (80) attribute SHOULD be used with RADIUS
   messages that are described in this memo, as defined in [RFC3579].

New:

   The Message-Authenticator (80) attribute [RFC3579] SHOULD be used
   with RADIUS messages that are described in this memo."

In Section 7:

Move the following references from Section 7.1 Normative References to
Section 7.2 Informative References:

   [I-D.ietf-isms-secshell]
              Harrington, D., Salowey, J., and W. Hardaker, "Secure
              Shell Transport Model for SNMP",
              draft-ietf-isms-secshell-12 (work in progress),
              October 2008.

   [I-D.ietf-isms-transport-security-model]
              Harrington, D. and W. Hardaker, "Transport Security Model
              for SNMP", draft-ietf-isms-transport-security-model-09
              (work in progress), October 2008.

   [RFC4252]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Authentication Protocol", RFC 4252, January 2006.

Move the following references from Section 7.2 Informative References to
Section 7.1 Normative References:

   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", RFC 3579, September 2003.

   [RFC5080]  Nelson, D. and A. DeKok, "Common Remote Authentication
              Dial In User Service (RADIUS) Implementation Issues and
              Suggested Fixes", RFC 5080, December 2007.

---

From: "Ira McDonald" <[email-masked]>
Date: Wed, 7 Jan 2009 14:03:44 -0500

Hi,

With all due to respect to you SNMP expert folks.

The "I" in "ISMS" stands for "Integrated".  From my
onlooker's perspective, Dave Nelson seems to be
saying that there are some "miraculous security
happens here" loose ends.  Others seems to be
saying "that's OK - because we could recharter
ISMS".  Not very comforting to operators who are
all pragmatists at heart.

While writing this, I just saw Dave's proposed
changes to the draft - which all seem good to
me.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: [email-masked]
winter:
  579 Park Place  Saline, MI  48176
  734-944-0094
summer:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 7 Jan 2009 14:10:45 -0500

>   authenticated principal to use SNMP over a specific secure Transport

In the line above s/specific secure Transport/secure Transport/ .

>   SNMP architecture, as described in RFC 3411 [RFC3411], does not make

In the line above s/SNMP architecture, as described in RFC 3411 [RFC3411]/
SNMP architecture [RFC3411]/ .

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Jan 2009 14:55:10 -0500

--On Wednesday, January 07, 2009 01:59:55 PM -0500 Dave Nelson 
<[email-masked]> wrote:

> Based on the discussion so far, I'd like to propose the following
> revisions to the draft:

All of these look good to me, with a couple of exceptions....

-- Jeff

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 7 Jan 2009 15:13:53 -0500

Jeffrey Hutzelman writes...
 
>>        Confidentiality-Protection.

Yeah, something is out of sequence.  Let's try that again, shall we?

Old:

   Refer to [I-D.ietf-radext-management-authorization] for a detailed
   description of these attributes.  From the perspective of the NAS,
   these attribute and value pairs indicate that the user is authorized
   to use SNMP using an SNMP secure Transport Model.

New:

The Old was actually the New, and the "real" Old had been omitted.  Sorry.

>>    There are good reasons to provision USM access to supplement AAA-

Yes, I think we do.  This addresses a different issue.  Combining a secure
transport model with a non-TSM security model is indeed NOT RECOMMENDED.
The text you question is a recommendation for operators to provision a
non-AAA method of SNMP access.  This is the analog of maintaining a local
/etc/passwd file as a back-up to NIS, for situations when the remote
authentication server is unreachable.  This text recommends configuration of
"pre-ISMS" mechanisms as a fall-back, in the case that an AAA server becomes
unreachable for any period of time.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Jan 2009 16:30:56 -0500

--On Wednesday, January 07, 2009 03:13:53 PM -0500 Dave Nelson 
<[email-masked]> wrote:

>>>    Combining a secure transport with RADIUS
>>>    authentication/authorization, and the SNMPv1 or SNMPv2c or USM
>>>    security models is NOT RECOMMENDED. See the coexistence section of
>>>    [TMSM]."
>>

I read the text quoted to specifically NOT RECOMMEND combining a 
_RADIUS-using_ transport model with a non-TSM security model.  While I'm 
pretty sure we recommend elsewhere against combining secure transports in 
general with non-TSM security, that's out of the narrow scope of this 
document.

> authentication server is unreachable.

Oh, I see.  You're not talking about using USM with a secure transport, but 
rather about provisioning both secure-transport+RADIUS+TSM _and_ USM 
separately.  That's a good recommendation, and I don't object to having it 
in this document, but I think it perhaps also belongs in the TMSM or TSM 
documents, since it really is not specific to RADIUS.

-- Jeff

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 7 Jan 2009 16:46:20 -0500

>> Yes, I think we do.  This addresses a different issue.  Combining
>> a secure transport model with a non-TSM security model is indeed
>> NOT RECOMMENDED.
>
> _RADIUS-using_ transport model with a non-TSM security model.  While
> I'm pretty sure we recommend elsewhere against combining secure 
> transports in general with non-TSM security, that's out of the 
> narrow scope of this document.

Well, as long as the text that Dave Harrington provided says the right
thing, you can simply ignore my imprecise paraphrasing.  :-)  Are we OK on
that?

> Oh, I see.  You're not talking about using USM with a secure 
> transport, but rather about provisioning both secure-transport+
> RADIUS+TSM _and_ USM separately.

Yeah.  I'll take another look at the wording any try to make that more clear
in the -05 version.

> That's a good recommendation, and I don't object to having it in
> this document, but I think it perhaps also belongs in the TMSM or TSM

Umm...  OK.  We'll leave it in this draft.  The TMSM and TSM documents are
not my fish to fry, but I'll observe that they are not in any way
AAA-specific, so this recommendation may not really fit there, either.

---

From: "David Harrington" <[email-masked]>
Date: Wed, 7 Jan 2009 16:52:51 -0500

Hi,
> AAA-specific, so this recommendation may not really fit there,
either.

Well, the non-reachability issue probably applies to CAs and Kerberos
servers, as well as AAA servers so I'll add somethng generic about
having a fallback authentication mechanism to either the TMSM or the
TSM doc.

dbh

---

From: "David Harrington" <[email-masked]>
Date: Wed, 7 Jan 2009 17:01:55 -0500

I think you would be better to describe the two use cases, which each
have authn and authz aspects, and to describe that the scope of the
current document is ONLY the service authn/authz use case.

In the RADIUS for SNMP Access Control document, we can discuss how a
single-sign-on approach might be used, reusing the service authn
identity as the access control authn identity. I think this discussion
does not belong in the RADIUS for Transport Models document, since we
are not addressing any access control aspects.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dave Nelson
> Sent: Wednesday, January 07, 2009 2:00 PM
> To: [email-masked]
> Subject: Re: [Isms] WGLC: radius-usage-04
> 
> authentication/authorization,

---

From: "David Harrington" <[email-masked]>
Date: Wed, 7 Jan 2009 17:09:40 -0500

Hi,

If you are that concerned about the discussion happening, I suggest
you publish a "RADIUS Usage for SNMP Access Control Models" as an
individual draft, so it provides a lingering reminder that the WG is
supposed to work on such a thing. Personally, I think it is an
important thing to work on.

I think publishing an individual internet draft would be better than
continually conflating the two use cases by adding references to SNMP
access control in the RADIUS Usage for Transport Models document.

my $.02
dbh

> Sent: Wednesday, January 07, 2009 1:30 PM
> To: [email-masked]

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 7 Jan 2009 17:24:33 -0500

> I think you would be better to describe the two use cases, which 
> each have authn and authz aspects, and to describe that the scope
> of the current document is ONLY the service authn/authz use case.

I've never thought of this as two separate use cases.  I've always thought
of it as two halves of a single problem, arbitrarily divided by WG processes
and by the SNMP architecture.  However, let me ponder this for a while.  It
wouldn't be the first time I've adjusted my viewpoint in grappling with the
RADIUS-related issue of SNMP.  :-)  Perhaps I can propose some better text
that divides the problem into separate use cases, instead of simply
first-half and second-half.

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 7 Jan 2009 17:58:21 -0500

> ...I suggest you publish a "RADIUS Usage for SNMP Access Control 
> Models" as an individual draft, so it provides a lingering reminder
> that the WG is supposed to work on such a thing.

Ah. The old "write an I-D or be quiet" comeback, eh?  :-)

Well, maybe I can find some time to do that prior to IETF-74.  We'll see.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Jan 2009 00:03:32 +0100

> database, if it is so configured.

Strictly speaking, a UNIX shell never authenticates someone; a shell
is forked (either by login or by sshd or ...) once authentication has
been completed and the proper user and group ids have been setup and
the proper process environment has been established. In other words,
the identity authenticated by SSH never really leaves the SSH daemon
in the form of a username that must be trusted by the shell; the shell
itself has no choice about its users.

This might not be relevant but I thought a clarification how things
actually work won't hurt either.

/js

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 7 Jan 2009 18:23:50 -0500

> Strictly speaking, a UNIX shell never authenticates someone; 
> a shell is forked (either by login or by sshd or ...) once 
> authentication has been completed and the proper user and group
> ids have been setup and the proper process environment has been
> established.

OK, you're right. It's typically the login process, not the shell.

> In other words, the identity authenticated by SSH never really
> leaves the SSH daemon in the form of a username that must be 
> trusted by the shell; the shell itself has no choice about its
> users.

Am I mistaken that SSH can pass the username to login so that login only
prompts for password, and not username?

Can SSH be configured so that the password check is bypassed, or am I
thinking of rlogin?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Jan 2009 00:57:06 +0100

> Can SSH be configured so that the password check is bypassed, or am I

If the SSH daemon figures out that it has to authenticate using a
password or using keyboard interactive, on most systems it will simply
call into the pluggable authentication modules (PAM) library. And the
PAM mechanism usually distinguishes between:

- account verification - is the account still allowed to be used?
- user authentication - is the user the one he claims to be?
- password change authorization - is the user allowed to change a password?
- session management - what needs to be done before and at the end of a 
  user's session?

PAM was created as an effort to factor these things out of an
increasing number of daemons that need to authenticate users and
establish sessions (login, telnetd, ftpd, sshd, ...). By simply
writing new PAM library modules or configuring existing PAM modules,
you can realize almost any policy without touching the source of any
daemons. If you want, you can configure PAM to accept any
password. (On many systems, you can find the details of what really
happens in /etc/pam.d.)

Anyway, if you ssh into a box and you get prompted for the password,
then you are still talking to the ssh daemon and once the daemon
declares (potentially by calling PAM) that it likes your password, it
will setup the process environment and fork a shell (or whatever
service you requested) for you.  The login program is not involved in
all of this; the central cornerstone on most systems is the PAM
library, not the login program (which is at the end just a wrapper
around PAM).

/js