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

From: "David Harrington" <[email-masked]>
Date: Mon, 31 Mar 2008 19:47:46 -0400

Hi,

I have reviewed this document. Comments below.

<overall>
I found the text within the document well-written, and much more
compatible with other ISMS documents than I recall was true of
previous versions. There is still much work to be done however.

I found the document a little hard to read because background info on
RADIUS, info on the managament-policy-id related attributes, and the
mapping to SNMP are all mushed together. Throughout the document there
are clauses/phrases such as "as defined in this document" and "as
described herein" that are effectively forward references to a
discussion of the management-policy-id attributes which is done
somewhat late in the document. I found this style irritating. Why not
tell us what the attributes are early on, and then you don't need all
the "as defined later in this document" phrases.

In discussing the mapping to SNMP, PLEASE assume that the
management-policy-id has already been accepted by the IETF. It makes
no sense to publish this document if that is not true, so the status
of the attributes should not need to be endlessly qualified - just
assume they are approved. That measn a lot of the phrases like "RADIUS
servers compliant to this specification" can just be reduced to
"RADIUS servers".

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).

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. State that
readers of this "mapping" document should already be aware of how
RADIUS works, and the management-related attributes. If you do this,
you can probably eliminate most of the tutorial for RADIUS and the
management-related attributes and just focus on doing the mapping to
SNMP.
</overall>

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

section 1.1 - we don't have modules in ISMS, we have models and
subsystems.
s/secure transport module/secure transport model/
s/modules/models/ or s/modules/subsystems/
I'm sure there are more uses of module in this document. They should
be replaced accordingly.

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

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 Managament-Policy-ID (such
as "Operator"), and a level of Transport-Protection. Apparently,
radext will not permit us to select the transport-protocol, and they
certainly will not allow us to specify a spewcific SNMP transport
model. Right?

section 2 discusses PAM; how do RADIUS servers in a Windows
environment do this? Is there a Windows equivalent?

s/rely of/rely on/

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.

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."/
OR
   RADIUS servers MAY use the management-related hint attributes to
inform 
   the decision whether to accept or reject the authentication request
for
   the SNMP service." 
(but isn't the hint really part of an authorizarion request rather
than an authentication request? I might be able to authenticate who I
am, but still not get approval to access the SNMP service.")

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

"   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.

"   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? I haven't seen one use these. 
I think this is between RADIUS and the transport protocol that is
using RADIUS, such as SSH. I don't think SNMP has anything to do with
this, and there is no place in the ISMS architecture to specify these
values. I am not sure they should be discussed in this document.

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

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.

section 3 shoul dbe part of the introduction to RADIUS and the
management related attributes. It seems out of place here.

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

Paragraph three discusses selecting SNMPv1 and SNMPv2c. I think the
discussion of using RADIUS with these needs further discussion.
Currently, SNMPv1 can be used with an SSH tunnel, with no transport
model to provide a binding; we might deveop a transport model with a
binding. The RADIUS attributes for managament, 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".

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

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