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

["David B. Nelson" <d.b.nelson at comcast.net>]

David Harrington Writes...

> I am only suggesting that the design of the document should be that
> it is specifically an SNMP mapping to these documents, as if there
> were also CLI mapping documents and Netconf mappings documents, etc.

OK. I understand.  You want us to design the document following an SMNP-like
architecture, with abstract subsystems and concrete models.  Personally, I
think that's asking a bit much, but we'll see what we can do.

> My objection is to the use of "recommended".

Hmmm.  "RECOMMENDED" is an RFC 2119 keyword, synonymous with "SHOULD".  From
that RFC:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

> Recommending is what you do when you're trying to sell something.

So, we should issue an errata against RFC 2119?  :-)

Seriously, though, it's in the "RECOMMENDED" sense that I used
"recommended", but I think we can easily wordsmith the text you find
confusing to fix that issue, perhaps just substituting "SHOULD".  Consider
it done.

> I am not complaining about them being bundled together in RADIUS
> messages. They are two separate concepts, even if they are mixed
> together in RADIUS messages.

Agreed.

> RADIUS attributes used for proving a user's identity are about
> authentication. RADIUS attributes that are about the provisioning
> of the approved service are about authorization.

Agreed.

> It would help if you used the words correctly in text.

I sometimes type one when I meant to type the other, so if you find such a
typo please bring it to my attention.  I fully understand the conceptual
difference.
 
> > >    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'll let you start a thread on that topic.

Since others have weighed in on this, I will start another thread.

> I think the Management-Policy-ID, and the Transport-Protection
> attributes should be captured by an SNMP Transport Model, and stored
> in the SNMP LCD as part of the transport-specific information
> received. This will make it available for later use by access control
> models.

Is this an "Implementation Note"?  Is it your intent that this document
places this requirement on the SNMP engine implementation?

> I suggest making the isms document SNMP-like, and the radext document
> RADIUS-like.

Sounds nice, but I'm not sure I'm up to the task.  :-(

> Yes, it's not the completeness or correcetness I have concerns with.
> There are some open issues in ISMS, and this paragraph may change as
> we resolve those open issues.  We need to discuss this further.

OK.  Are you suggesting that the RADIUS Usage document cannot be competed
until the remaining issues in the other ISMS documents are resolved?

> In addition, there are some other issues with SNMPv1/v2c that may come
> into play if the radext attributes do not support specifying a
> particular SNMP transport model or a specific transport protocol
> (which would permit us to assume which specific SNMP transport model
> is involved):
> 
> > > 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.
> 
> This also will require further discussion.

OK. Let's start a discussion of that.  I don't think that having the RADIUS
Server, and the system administrator, specify particular transport protocols
and granular security parameters of such protocols is ultimately useful.  It
is certainly possible to define RADIUS attributes to do that, even if it
turns out there are a large number of them and it takes us quite a while to
define them correctly.  My concern is that it will be hard for an
administrator to apply them correctly.  Of course, RADIUS Server
implementations could be created with wizards and other UI features to
assist in creating correct configurations.  I'm just not sure that's where
we want or need to go.


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