>>>>> "Chris" == Chris Lonvick <[EMAIL PROTECTED]> writes:
Chris> Is Section 8 in draft-ietf-syslog-protocol-16.txt
Chris> sufficient? Alternatively, Section 6 in RFC 3164 is fairly
Chris> comprehensive.
Both of these look good. My main question with them is whether you
believe it is a requirement to address all these threats or whether
addressing a subset is sufficient.
>>
>>
>> 2) Define mechanisms to address these threats.
>>
>> So, questions for the threat model include things like whether
>> confidentiality is important or whether integrity of mesages is
>> sufficient.
>>
>> Depending on the threat model here are some possible solutions:
>>
>> 1) Require some transport like syslog over TLS|DTLS be
>> implemented.
Chris> RFC 3195 requires the use of RFC 3080 which requires TLS.
Noted.
>> 2) Require that all senders implement signatures stored in
>> structured data as an option.
Chris> That's likely addressed through syslog-sign.
Agreed.
>> I don't think you need to commit to one of these options now.
>> However, you do need to reflect the security issues in the
>> charter.
Chris> The questions for you:
Chris> - Do we need to produce a threat model in a new document?
No, although you probably need to decide which threats you are
addressing.
Chris> - Can we state that the threats will be addresses in
Chris> syslog-sign and 3195bis? I will also note that there is a
Chris> group of implementors who have already done syslog/tls. I
Chris> suspect they would like to codify this in a standard and
Chris> that may also address the threats.
You need to require everyone who implements syslog-protocol to
implement your mandatory to implement security mechanism. That could
be syslog-sign or 3195bis, but you'd have to actually make that
normative requirement in protocol.
I think the real question here is what mechanism can you choose that
people will actually implement.
--Sam
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
