Subject: [Isms] Session timeouts?

From: "David B. Nelson" <[email-masked]>
Date: Wed, 2 Apr 2008 13:11:49 -0400

I'm starting a separate thread to discuss the issue of providing
RADIUS-provisioned session timeouts for SNMP connections.  This came up in
the review comments on the RADIUS Usage for SNMP draft.

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

A couple of folks opined that this is useful.  RADIUS has a long history of
provisioning session timeouts for the services that it authorizes, dating
back to its original use in terminal servers and dial-up remote access
servers.  For example, the RADIUS usage guide for 802.1X (RFC 3580)
describes how the RADIUS attributes Session-Timeout (27) and Idle-Timeout
(28) affects network connections moderated by an 802.1X Controlled Port.  I
think the RADIUS usage guide for SNMP should do likewise.

The issue in question seems to be where this happens, and the only
reasonable answer seems to be in the secure transport (e.g. SSH).  ISMS
cannot place requirements on SSH usage of RADIUS generally, but we can
probably place requirements on SSH usage of RADIUS when SSH is used to
support an SNMP Transport Model.

Does that seem reasonable?

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

---

From: "David Harrington" <[email-masked]>
Date: Wed, 2 Apr 2008 13:25:13 -0400

Hi,

Since we don't know which implementation of SSH or which
implementation of RADIUS will be used, would it make sense to simply
add an implementer note that they might want to configure their
implementation to utilize such parameters?

Are there some values we should recommend as being appropriate to
enhance interoperability? Or would this even affect interoperability?
Our SSH transport model is designed to handle finding that no session
is currently open (so it opens one), or that a session might have
terminated between the time of receiving a request and sending the
response (so it discards the response).

Is this actually germane to the SNMP mapping? Would this be better
discussed in the radext draft for mgmt attributes?

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David B. Nelson
> Sent: Wednesday, April 02, 2008 1:12 PM
> To: [email-masked]
> Subject: [Isms] Session timeouts?
>

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 2 Apr 2008 13:45:38 -0400

> implementation to utilize such parameters?

That presumes that it's a configuration option, i.e. that the feature has
been coded into the implementation and simply needs to be enabled at run
time.  That may not always be the case.
 
> enhance interoperability? Or would this even affect interoperability?

I think all we need to specify is that an SNMP session is closed by the SSH
server after Session-Timeout seconds, or after Idle-Timeout seconds elapse
between SNMP messages.  That is to say, that the SSH server takes notice of
the session limiting authorization information.

> response (so it discards the response).

Right.

> discussed in the radext draft for mgmt attributes?

Well, the RADEXT draft defines _new_ RADIUS attributes for management
authorization.  It does not indicate how those attributes are used in a
specific application (e.g. SNMP, NETCONF, et. al.), although it does
describe how they are generally used in an application agnostic fashion.  It
does not layer additional usage guidelines _existing_ attributes, for
specific applications.  I think it is preferable to define attributes in one
place (e.g. the base document RFC 2865 or the Management Authorization
draft) and explain how they are applied in a particular application in a
separate draft (like RFC 3580 does for 802.1X).

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 02 Apr 2008 15:34:23 -0400

> time.  That may not always be the case.

True, but that is a problem for the ssh implementors.  I think it's 
entirely reasonable to specify RADIUS attributes which describe session 
timeout behavior for SSH, with the understanding that while there is a 
standard way to describe the timeouts, there is no requirement that an SSH 
server actually implement them.

-- Jeff

---

From: "David B. Nelson" <[email-masked]>
Date: Wed, 2 Apr 2008 15:55:15 -0400

Jeffrey Hutzelman writes...

> I think it's entirely reasonable to specify RADIUS attributes which
> describe session timeout behavior for SSH, with the understanding that 
> while there is a standard way to describe the timeouts, there is no 
> requirement that an SSH server actually implement them.

Right.  RADIUS standards do not create requirements for applications to
implement the use of certain attributes, or support certain features; only
end users do that.  The most that the RADIUS documents dictate is how the
attributes are to be used, if the feature is implemented. 

I think it's useful to point out what RADIUS features are available for use
with SNMP Transport Models.  That's how I would propose to handle the
session timeout issue for ISMS, to describe how RADIUS attributes are used
to provision this feature, and suggest (dare I say recommend?) how it might
be implemented, e.g. in the SSH server.

If it turns out that there are Security Considerations surrounding the
decision to implement session timeouts (or not) we could describe them.

---

From: Kaushik Narayan <[email-masked]>
Date: Wed, 02 Apr 2008 15:15:27 -0700

Hi David,

I think it is useful to specify that the timeout attributes be included in
the RADIUS response but agree that it would be up to implementations to act
on these attributes. This does not effect the SNMP mapping but creates
requirements for transport implementations that may be used to support ISMS.

Regards,
 kaushik

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 03 Apr 2008 07:52:13 -0700

>>>>> "DBN" == David B Nelson <[email-masked]> writes:

DBN> I think it's useful to point out what RADIUS features are available for use
DBN> with SNMP Transport Models.

How about an appendix of potentially beneficial RADIUS attributes that
implementations may wish to consider using and what they mean if they do
use them?  One reason I say "appendix" is that as RADIUS changes over
time I'm sure that the new parameters potentially added in the future
won't discuss it's context within every mechanism that might be using
RADIUS (like the ISMS transport).  So it seems to me to be more
"advice", which sounds more like (highly-useful) appendix material.
-- 
Wes Hardaker
Sparta, Inc.
_______________________________________________
Isms mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isms