[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: [Isms] What granularity of attributes do we need for the secure transport?
- To: <radiusext@ops.ietf.org>
- Subject: FW: [Isms] What granularity of attributes do we need for the secure transport?
- From: "David B. Nelson" <dnelson@elbrysnetworks.com>
- Date: Fri, 4 Apr 2008 14:56:49 -0400
- Organization: Elbrys Networks, Inc.
There is a discussion going on currently in the ISMS WG with regard to
authorization and/or provisioning of management access to a NAS,
specifically with respect to the security properties of the transport
protocol (for remote management). Some of this discussion has been specific
to SNMP and the ISMS work, but some is more generally related to NAS
management authorization.
I'll forward (cross-post) those messages of general interest to RADEXT. You
may also review the ISMS WG mailing list archives for additional
information.
> -----Original Message-----
> From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On Behalf Of
> David B. Nelson
> Sent: Friday, April 04, 2008 1:57 PM
> To: isms@ietf.org
> Subject: Re: [Isms] What granularity of attributes do we need for the
> secure transport?
>
> David Harrington writes...
>
> > I do not believe we need to provision the security protocol; ...
>
> Meaning we don't need to specify such things as the selection of optional
> modes, cipher suite, authentication mechanism, certificate chains, and so
> forth. Right?
>
> > I think we should allow an operator to decide which secure transport
> > they want to require as a condition of granting access to the SNMP
> > service.
>
> Just the transport protocol name? Or do you want to sub-specify versions,
> e.g. SSHv2, TLSv1? If you want to specify IPsec as one of these, do you
> need to specify such things as IKEv2?
>
> I think the devil is in the details.
>
> If I understand your position correctly, to want to augment the existing
> Management-Protocol-Protection attribute, which specifies the level of
> security in an abstract fashion, with a reinstated
> Management-Transport-Protocol attribute which names the mandated protocol
> (and maybe the protocol version). Right? Do you anticipate that there
> could be only one of these attributes in a RADIUS Access-Accept message,
> or could there be more than one (i.e. acceptable alternatives)?
>
> That seems to be a middle ground choice, between having only an abstract
> assertion about the security level and having all the details and
> parameters
> related to a secure transport protocol.
>
> What do others think about this decision point?
>
> -- Do we need only an abstract security level assertion?
>
> -- Do we need the transport protocol name?
>
> -- Do we need the transport protocol version?
>
> -- Do we need any further details of security parameters?
>
> _______________________________________________
> Isms mailing list
> Isms@ietf.org
> https://www.ietf.org/mailman/listinfo/isms
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>