Subject: [Syslog] Charter comments from IESG Review

From: Sam Hartman <[email-masked]>
Date: Thu, 05 Jan 2006 17:12:15 -0500

Hi.  The IESg reviewed the proposed syslog charter at today's telechat
and decided that it requires revision.  The main concern seems to be
the lack of a mandatory to implement security mechanism.  I indicated
this might be the case in the Vancouver meeting.

so, you definitely need to have some sort of mandatory to implement
security mechanism.  I'm not quite sure what needs to be said about
this in the charter.
But the working group will need to:

1) Identify a threat  model for syslog

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.

2)  Require that all senders implement signatures stored in structured
    data as an option.

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.

--Sam

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 6 Jan 2006 10:25:00 -0800 (PST)

Hi Sam,

> 1) Identify a threat  model for syslog

Is Section 8 in draft-ietf-syslog-protocol-16.txt sufficient? 
Alternatively, Section 6 in RFC 3164 is fairly comprehensive.

> 1) Require some transport like syslog over TLS|DTLS be implemented.

RFC 3195 requires the use of RFC 3080 which requires TLS.

> 2)  Require that all senders implement signatures stored in structured

That's likely addressed through syslog-sign.

> However, you do need to reflect the security issues in the charter.

The questions for you:

- Do we need to produce a threat model in a new document?

- Can we state that the threats will be addresses in syslog-sign and 
3195bis?  I will also note that there is a group of implementors who have 
already done syslog/tls.  I suspect they would like to codify this in a 
standard and that may also address the threats.

Thanks,
Chris

---

From: Sam Hartman <[email-masked]>
Date: Fri, 06 Jan 2006 14:36:03 -0500

>>>>> "Chris" == Chris Lonvick <[email-masked]> 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.

    >> 1) Require some transport like syslog over TLS|DTLS be

    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.

    >> However, you do need to reflect the security issues in the

    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

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 6 Jan 2006 21:12:34 +0100

Sam

I struggle to think what a security system would look like when the protocol is
purely simplex, apart from a MAC to give integrity with some shared secret
transmitted totally out of band.

Are there any examples of simplex security elsewhere in the IETF?

Tom Petch

---

From: Sam Hartman <[email-masked]>
Date: Fri, 06 Jan 2006 16:27:41 -0500

>>>>> "Tom" == Tom Petch <[email-masked]> writes:

    Tom> Sam I struggle to think what a security system would look
    Tom> like when the protocol is purely simplex, apart from a MAC to
    Tom> give integrity with some shared secret transmitted totally
    Tom> out of band.

By this do you mean without two-way communication?

If so, yes, both S/MIME and OpenPGP support this model.  However I'll
point oun that it is not a requirement that syslog work that way; for
example RFC 3195 certainly has connections.

---

From: "Tom Petch" <[email-masked]>
Date: Sat, 7 Jan 2006 21:22:15 +0100

----- Original Message -----
From: "Sam Hartman" <[email-masked]>
To: "Tom Petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 06, 2006 10:27 PM
Subject: Re: [Syslog] Charter comments from IESG Review

> By this do you mean without two-way communication?
Yes, I meant without two-way communication

> example RFC 3195 certainly has connections.
I'll look at those, thanks.  I agree syslog could be, perhaps should be for
meaningful security, but often at present is not, so I wanted to see what
security was
possible with just one way communication

Tom Petch