Subject: [Isms] questions about draft-ietf-isms-radius-usage-01

From: li chunxiu <[email-masked]>
Date: Tue, 19 Feb 2008 11:36:53 +0800

1 .In the second paragraph in"1.1general" of
draft-ietf-isms-radius-usage-01, what does "a common identity" of the RADIUS
protocol refer to?
2. In page 4: "When that service provisioning does not match the
capabilities of the NAS, or of the particular interface to the NAS over
which the user is requesting access, RFC2865 [RFC2865] requires that the NAS
MUST reject the access request." What does "the particular interface" refer
to? "the NAS MUST reject the access request." Means the NAS reject the user
directly or the RADIUS server do the reject action? It seems ambiguous here.
3. in page 6" 2.  RADIUS Usage for SNMP Transport Models", why "the
distinction between user authentication and service authorization for the
SNMP Transport Models and the SNMP Transport Security Model(TSM) is
relevant, and perhaps important."? Does it need some details for it?
4 . the content of the last paragraph of page 4 and " 2.1.  RADIUS
Authentication for Transport Protocols" in page 7 belongs to one meaning,
maybe they could be described in a whole part to express compactly.

Thank you very much!
Chunxiu li

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

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 20 Feb 2008 08:40:17 -0500

Li Chunxiu writes...
 
> 1 .In the second paragraph in "1.1 general" of
> draft-ietf-isms-radius-usage-01, what does "a common identity" of the
> RADIUS protocol refer to?

   The RADIUS protocol also provides the advantage of allowing a common
   identity to be used with or shared across disparate management
   protocols, since the other network management interfaces such as
   NETCONF are capable of authentication with the same RADIUS server.

This means that a common identity database is often behind the RADIUS
server, such as NIS, LDAP, Active Directory, etc.  While RADIUS servers
commonly provide a native user database feature, most organizations
deploying RADIUS tie their RADIUS servers into an existing authentication
infrastructure.  In addition, it means that any device (NAS) that
authenticates against a common RADIUS server (or set of RADIUS servers in a
common administrative domain) will be able to authenticate users against a
common identity database.

> which the user is requesting access, RFC2865 [RFC2865] requires that the
> NAS MUST reject the access request." What does "the particular interface"
> refer to?

It means the physical or virtual interface for or over which service request
is being requested.  In the simplest case of an 802.1X authentication is it
the 802.1D switch port.  The interface in question may be represented using
the NAS-Port or NAS-Port-ID attributes.

> "the NAS MUST reject the access request." Means the NAS reject the
> user directly or the RADIUS server do the reject action?

   When that service provisioning
   does not match the capabilities of the NAS, or of the particular
   interface to the NAS over which the user is requesting access, RFC
   2865 [RFC2865] requires that the NAS MUST reject the access request.
   For a description of the basic set of attributes, refer to [RFC2865].

It means that the NAS (the device that contains the RADIUS Client) must
perform the rejection.  By the way, this is not a new normative requirement.
It is simply a reiteration of the requirements of RFC 2865, placed here for
background information.  Previous ISMS WG comments requested a basic review
of "RADIUS Theory of Operation" in this document.

> It seems ambiguous here.

Hmmm.  The statement "... requires that the NAS MUST reject the access
request." seems pretty clear to me.  Can you suggest some alternate text?

> relevant, and perhaps important."?

It is relevant because of the way in which SSH implementations have
traditionally integrated with RADIUS Clients.  Those SSH implementations
traditionally seek to obtain user authentication (e.g. validation of a
username and password) from an outside authentication service, often via a
Pluggable Authentication Module (PAM) style interface.  The service
authorization in traditional SSH server implementations comes via the
restrictions that the operating system (OS) shell (and file system, etc.)
place on the user by means of access controls tied to the username or the
username's membership in various user groups.  These OS-style access
controls are distinct from the service provisioning (authorization) features
of RADIUS.  If we wish to use existing SSH server implementations (or
slightly adapt them) for use with SNMP Transport Models, we need to be aware
that the RADIUS service authorization information may or may not be passed
along to the relevant SNMP modules by the SSH module.

> Does it need some details for it?

Perhaps.  Does the above explanation help?

It may also help to explain why RADIUS service authorization is desirable in
the first place.  If that isn't clear from other sections of text in the
document, it should be clarified, as well.

> maybe they could be described in a whole part to express compactly.

It could be merged.  As I indicated above, a previous commenter requested
that a basic RADIUS theory of operation be provided as introductory material
before any SNMP specifics were discussed.  This leads to some redundancy,
wherein the material is first reviewed in general terms and is later
discussed again in the specific context of SNMP Transport Models.

---

From: li chunxiu <[email-masked]>
Date: Fri, 22 Feb 2008 11:59:45 +0800

Hi,David B.Nelson
Thank you very much for your detailed explanation for my questions. 
And I am sorry for the bad format of my email, I will take care of it next
time. Ok，I understand the answers now, and there are very clear.
And I also understand the logic of general terms and specific context now. 
Thank you!

a mistake of this draft:
sec 5.Security Considerations 
   Additional security considerations for use of SNMP with secure
   Transport Models [sshtm] and the Transport Security Model [sshtm] are
   found in the Security Considerations sections of the respective
   documents.

there is a mistake of 2 abbreviations.

Chunxiu li

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 21 Feb 2008 23:24:33 -0500 (EST)

> there is a mistake of 2 abbreviations.

Which is to say, there are two references to [sshtm], at least one of
which is wrong.  In fact, they are both incorrect - the first should be to
[tmsm] and the second to [tsm].  Furthermore, the [tsm] reference itself
uses the wrong title; it should be "Transport Security Model for SNMP".

-- Jeff

---

From: li chunxiu <[email-masked]>
Date: Fri, 22 Feb 2008 14:09:45 +0800

Hi, Jeffrey Hutzelman
Yes, I agree with your opinion. thank you!

Chunxiu li

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 22 Feb 2008 09:17:44 -0500

Li Chunxiu writes...

> And I am sorry for the bad format of my email...

I thought your e-mail was easy to read.  Thank you for your questions and
comments.

> there is a mistake of 2 abbreviations.

OK. Thanks! I'll fix that.

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 22 Feb 2008 09:18:51 -0500

Jeffrey Hutzelman writes...

> uses the wrong title; it should be "Transport Security Model for SNMP".

Will fix.  Thanks!