Subject: review of draft-ietf-radext-management-authorization-00.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Sep 2007 15:16:30 +0200

Hi,

I have read <draft-ietf-radext-management-authorization-00.txt> and in
general I believe this document is in good shape and useful. I have
some issues which I tried to write up in the radiusext WG way...

---

Description: mention NETCONF as framed management protocol
Submitter name: Juergen Schoenwaelder
Submitter email address: [email-masked]
Date first submitted: Thu Sep  6 14:47:36 CEST 2007
Reference:
Document: draft-ietf-radext-management-authorization
Comment type: E
Priority: 2
Section: 3
Rationale/Explanation of issue:

I think the first paragraph should also mention NETCONF as a Framed
Management protocol.

--

Description: add missing article
Submitter name: Juergen Schoenwaelder
Submitter email address: [email-masked]
Date first submitted: Thu Sep  6 14:47:36 CEST 2007
Reference:
Document: draft-ietf-radext-management-authorization
Comment type: E
Priority: 2
Section: 4
Rationale/Explanation of issue:

s/containing policy name/containing a policy name/

--

Description: SNMP-Transport-Model vs. SNMP
Submitter name: Juergen Schoenwaelder
Submitter email address: [email-masked]
Date first submitted: Thu Sep  6 14:47:36 CEST 2007
Reference:
Document: draft-ietf-radext-management-authorization
Comment type: T
Priority: 1
Section: 7.1
Rationale/Explanation of issue:

Why is the value 1 associated with "SNMP-Transport-Model"? Should this
not be just "SNMP", perhaps implying SNMPv3? This would be more
consistent with example #4, no? In fact, the proposed RADIUS
attributes do not carry what really counts - the security level, e.g.
I might accept SNMP access as long as the actual security level is
providing authPriv, regardless how this is achieved. Well, since we do
not have a defined way to utilize RADIUS from SNMPv3/USM, this is
probably a mood point. Still, I think calling this enum just SNMP is
the better approach.

--

Description: SNMP policy mapping and the reality
Submitter name: Juergen Schoenwaelder
Submitter email address: [email-masked]
Date first submitted: Thu Sep  6 14:47:36 CEST 2007
Reference:
Document: draft-ietf-radext-management-authorization
Comment type: T
Priority: 2
Section: 8
Rationale/Explanation of issue:

Example #4 is nice but there is no agreement/specification how this
would work with SNMPv3 and ISMS is not chartered to figure this out.
Perhaps this can be addressed by adding a note saying.

  Note that there is currently no standardized way of implementing
  this management policy mapping for SNMPv3.

--

Description: rules for extending enumerations
Submitter name: Juergen Schoenwaelder
Submitter email address: [email-masked]
Date first submitted: Thu Sep  6 14:47:36 CEST 2007
Reference:
Document: draft-ietf-radext-management-authorization
Comment type: T
Priority: 2
Section: 12
Rationale/Explanation of issue:

The two new attributes Framed-Management-Protocol and
Transport-Protocol are enumerations that may need to be extended
(e.g. NETCONF is missing in the first one already). I suggest that the
IANA section spells out the rules for extending these enumerations,
e.g. by requiring a specification.

--

Description: local or not so local area networks
Submitter name: Juergen Schoenwaelder
Submitter email address: [email-masked]
Date first submitted: Thu Sep  6 14:47:36 CEST 2007
Reference:
Document: draft-ietf-radext-management-authorization
Comment type: E/T
Priority: 2
Section: 13
Rationale/Explanation of issue:

The first sentence in the security considerations kind of restricts
RADIUS and DIAMETER to "local area networks". I am not sure why this
should be useful or what breaks if the network is not a local area
network (however this is defined). I suggest to simple remove the
phrase "within local area networks" or if there is a reason for having
this restriction, then please add text which spells the reasons out.

--

/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/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 12 Nov 2007 17:43:21 -0500

Juergen Schoenwaelder writes...

> I think the first paragraph should also mention NETCONF as a Framed

Others have suggested this as well.  Will do.

> s/containing policy name/containing a policy name/

OK.

> not be just "SNMP", perhaps implying SNMPv3?

Others have made s similar suggestion, so I think something along the lines
of your recommendation is called for.

> This would be more consistent with example #4, no? In fact, the 
> proposed RADIUS attributes do not carry what really counts - the 
> security level, e.g. I might accept SNMP access as long as the 
> actual security level is providing authPriv, regardless how this is
> achieved.

That may indeed be useful...

> Well, since we do not have a defined way to utilize RADIUS from
> SNMPv3/USM, this is probably a mood point. Still, I think calling this 
> enum just SNMP is the better approach.

Yes.

>   this management policy mapping for SNMPv3.

OK.  This is currently something implementation specific.

> (e.g. NETCONF is missing in the first one already). I suggest that
> the IANA section spells out the rules for extending these
> enumerations, e.g. by requiring a specification.

Another reviewer commented in a similar fashion, that this draft should
provide more specific guidance to IANA than simply falling back on RFC 3775.
I'll add some text.

> phrase "within local area networks" or if there is a reason for 
> having this restriction, then please add text which spells the 
> reasons out.

No reason.  I'll remove the restriction.

Thanks for the through review.