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

[Kaushik Narayan <kaushik at cisco.com>]

Please find my reply inline.


On 4/1/08 12:44 PM, "David B. Nelson" <dnelson at elbrysnetworks.com> wrote:

> David Harrington writes...
> 
>> I have reviewed this document. Comments below.
> 
> Thank you for your thorough review.  I will respond to those issues that are
> easily resolved and highlight those which require further thought or
> discussion.
> 
>> I found the document a little hard to read because background info on
>> RADIUS, info on the management-policy-id related attributes, and the
>> mapping to SNMP are all mushed together.
> 
> This is something that will require further thought.  The authors added the
> introductory material in response to your comments on a previous version.  A
> plan to more clearly delineate the various elements will require some time
> spent in re-reading the material with an eye toward that objective.


<Kaushik>

The introductory text is brief to ensure that we do not end up copying
significant parts of other RFCs and drafts. We probably should avoid
significant work in this area unless people believe that the rest of the
specification is unclear because of missing context in the introduction.

</Kaushik>



>
> 
>> 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.
> 
> Hmmm.  That sounds like scope-creep.  I agree that we should avoid creating
> any gratuitous SNMP-specific dependencies, but this document is about RADIUS
> and SNMP, not about RADIUS and anything else.  Right?


<Kaushik>

I agree with David, the approach described in the document could be applied
to other management protocols such as NetConf etc. but that is not the
purpose of this document.

</Kaushik>



> 
>> section 2 discusses PAM; how do RADIUS servers in a Windows
>> environment do this?
> 
> PAM is an interface between an end-user data service (e.g. SSH) and an
> authentication service (e.g. RADIUS Client).  RADIUS Servers do not come
> into the picture.  PAM is common in Unix environments.  I don't know what
> the equivalent is in a Windows environment.
> 


<Kaushik>

The reference to PAM was meant to highlight some of the issues with existing
implementations where the OS-specific interfaces are used by SSHv2
implementations to integrate with the RADIUS client. This potentially
complicates how RADIUS attributes received by the RADIUS client are made
available to the SNMP layer. PAM was merely used as an example and the
intent was not to list each OS-specific interface.

</Kaushik> 


>> I might be able to authenticate who I am, but still not get approval
>> to access the SNMP service.")
> 
> That's true.  In that case one of two things would happen.  The RADIUS
> Server would return an Access-Accept message provisioning a default service
> for your profile that you are authorized to use, or more likely the RADIUS
> Server would return an Access-Reject message, because you are not authorized
> to use the service you are apparently requesting.

<Kaushik>

Service authorization is a coarse granular method to ensure that access to
the SNMP service is limited to operators/administrators, the RADIUS server
would probably be capable of authenticating the entire set of user's within
an organization.


</Kaushik>



 

>  
>> "   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?
> 
> Well, I'm not sure any of them do...  more like they should.  I think this
> needs some discussion.
> 
>> I think this is between RADIUS and the transport protocol that is
>> using RADIUS, such as SSH.
> 
> Quite possibly.
> 
>> I don't think SNMP has anything to do with this, and there is no
>> place in the ISMS architecture to specify these values.
> 
> There may not be a place in the ISMS architecture.  However, RADIUS has a
> long history of provisioning limits on the services that it authorizes, so
> it seemed natural to continue this practice with SNMP.
> 
>> I am not sure they should be discussed in this document.
> 
> If not here, then where?


<Kaushik>

Session timers and inactivity timers are commonly used for CLI access for
administration (with RADIUS/TACACS+). The timers may be used by the
transport protocol (sshd, telnetd) or the application spawned
(shell/terminal).

I agree with David that this fairly common and needs more discussion before
we dismiss it.

Regards,
 kaushik

</Kaushik>





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