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.