Re: [Isms] What granularity of attributes do we need for the secure transport?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 at ietf.org
https://www.ietf.org/mailman/listinfo/isms
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.